X

OpenBSDユーザーコーナー Part10

0318名無しさん＠お腹いっぱい。
垢版 |
2019/11/12(火) 23:29:58.94
>>316
Linuxカーネルは今や2100万行だ。まともに保守できるとは思えない。
BSDのように小さければ保守も楽だがこれだけ肥大化するともう手に負えない。
どうなっても誰も責任持てない。
0322名無しさん＠お腹いっぱい。
垢版 |
2019/11/13(水) 07:06:34.38
ドライバ込みの行数やろ？
コアな部分はそう多くないのでは
0323名無しさん＠お腹いっぱい。
垢版 |
2019/11/13(水) 08:55:54.90
>>311
read onlyにしてもセキュリティの弱さは避けられないみたいだが。

「vDSOは、その制限を克服しながらvsyscall機能を提供するために開発されました。わずか4つのシステムコールを許可する
静的に割り当てられた少量のメモリと、各プロセスで同じアドレスABIを使用すると、セキュリティが低下します。」
0326名無しさん＠お腹いっぱい。
垢版 |
2019/11/13(水) 13:54:37.02
>>323
そんな日本語にもなってない文章だされても、機械翻訳の誤訳でしょっていう感想にしかならんよ。
意味不明な文章じゃなくて、原文のURLを見せてよ。
0328名無しさん＠お腹いっぱい。
垢版 |
2019/11/14(木) 08:45:41.32
>>327
やっぱり誤訳だったな。
和訳では少量のメモリーってのがセキュリティを低下させる条件の一つになってるが
原文はそうじゃない。

とはいえ原文もやっぱり意図不明なのでさらにreference
ttps://stackoverflow.com/questions/19938324/what-are-vdso-and-vsyscall
を辿ると、これはvDSOにASLRが効かないことを問題視してたんだな。
肝心のASLRって単語をに抜いちまうとはwikipediaもひどい。

で、結論を言うとその記述は古い。
以下で分かる通り今ではvDSOにもASLRが効いてるので、その問題は解決されている。
ttps://wiki.ubuntu.com/Security/Features
これはUbuntuの例だが、
grep vdso /proc/*/smaps
とかしてみれば、手元のLinuxでもASLRが効いてることを確認できるぞ。
0329名無しさん＠お腹いっぱい。
垢版 |
2019/11/14(木) 18:15:38.54
>>328
いろいろ調べてもらってありがとう。でもこれって結局手間かけて面倒なことをしてるだけだね。

元々vdsoを導入した目的はシステムコールを速く実行するためだったはずなのに、結局目的を達成できてない。
ASLRができなくなってセキュリティを弱め、その代用として仮想システムコールを追加したためにかえって遅くなってしまった。
こんなことなら普通にカーネルランドとユーザーランドを切り替えたほうがよほどシンプルだと思うね。

未確認だけど、もし仮想システムコールが大量に発生するようなプログラムを動かし続けたらいずれカーネル側の
メモリが溢れてmemory overflow起こすなんてことはないだろうね。またセキュリティを気にしないといけなくなる。
カーネル側で仮想システムコールを実行するなんてことしなければこんなことを気にする必要もなかった。
0330名無しさん＠お腹いっぱい。
垢版 |
2019/11/14(木) 18:36:16.61
>>329

なんかまだ大幅に誤解してるみたいね。

> 元々vdsoを導入した目的はシステムコールを速く実行するためだったはずなのに、結局目的を達成できてない。

その判断は誤り。
達成できている。
vDSOなしだとユーザーランドからカーネルにコンテストスイッチして、またユーザーランドに戻る必要がある。
vDSOがあるおかげでコンテストスイッチなしで同じ機能を実現できてる。

> ASLRができなくなってセキュリティを弱め、

その判断も誤り。
初期の実装ではASLRに対応してなかったためそういう問題があったが
現在は対応済みのため解決している。

> その代用として仮想システムコールを追加したためにかえって遅くなってしまった。

その判断も誤り。
仮想システムコールって、要はPLT経由の共有ライブラリ関数呼び出しなわけで
オーバーヘッドは libc のシステムコールエントリーポイントを呼ぶのと変わらない。

vDSOなしだと、共有ライブラリ関数呼び出しとシステムコールの両方のオーバーヘッドがあったのが、
vDSOのおかげで、共有ライブラリ関数呼び出しのオーバーヘッドのみに変わり、
純粋に速くなってるわけ。
0332名無しさん＠お腹いっぱい。
垢版 |
2019/11/14(木) 18:58:36.32
>>330
> vDSOがあるおかげでコンテストスイッチなしで同じ機能を実現できてる。
でも仮想システムコール入れて遅くなってるよね

> 初期の実装ではASLRに対応してなかったためそういう問題があったが
> 現在は対応済みのため解決している。
対応って仮想システムコールでしょ。vDSOでASLRしてるとは書かれてない。

> 仮想システムコールって、要はPLT経由の共有ライブラリ関数呼び出しなわけで
さらっと書いてるけど、vDSOの仮想システムコールがPLT経由で呼び出してるだけというドキュメントはある？
0333名無しさん＠お腹いっぱい。
垢版 |
2019/11/14(木) 21:22:31.61
>>332
どのシステムコールがvDSOで提供されてるかチェックするだけでも仕組みの想像がつくから調べてみることをお勧めする。
想像つかないならドキュメントなんて読むんじゃなくて
ソースを読む方がいい。
めちゃくちゃ単純な仕組みなんだから。
0334名無しさん＠お腹いっぱい。
垢版 |
2019/11/14(木) 23:33:45.55
まあ今までの内容で大体はわかったけど、なんか筋が悪い気がする。考え方としてね。
せっかくカーネルをリング0で動かしてセキュリティがっちり守ってるのに、わざわざ共有メモリという抜け穴作って
速くなっただろって言ってる感じ。それで穴ができちゃってまずいことになったから仮想システムコールにしてこれで大丈夫だって。

普通に考えたらリング0とリング3の間でのやりとりが高速になればいいんだからハードでやった方が簡単で安全確実だろう。
CPUのメモリ制御に1個追加機能を持たせてソフトはそれ使うだけでいいようにする。
こうすればどのOSでもこれを利用すればいいから楽だ。
VMwareが出てきたとき、最初は全部ソフトでやってたが、CPUが仮想化技術に対応するようになったら
簡単に仮想化ができるようになった。これと同じ考えでCPUにリング間で安全・高速にメモリ共有する機能を
追加した方がよほど筋がいい。ソフト側で余計なことをしなくて済むしセキュリティも気にしなくて良くなる。
単なる個人的意見だけどね。
0335名無しさん＠お腹いっぱい。
垢版 |
2019/11/14(木) 23:45:34.54
穴が出るような処理なんてそもそもやってないんだよ。
頭の中で空想するんじゃなくてコード読もうよ。
0336名無しさん＠お腹いっぱい。
垢版 |
2019/11/19(火) 08:29:11.50
ちょっとググっただけでソースは読んでないけどvdsoで実装されてるのってgettimeofdayとかの時間取得系だけなんだよね？
0340名無しさん＠お腹いっぱい。
垢版 |
2019/11/19(火) 18:27:00.42
>>338
時刻取得とかに限定されてるのは統計的に一番呼ばれるシステムコールだからかな？
ファイル関係はvdso化のメリットがないとか？
0341名無しさん＠お腹いっぱい。
垢版 |
2019/11/19(火) 18:30:50.49
>>340
カーネルモードにコンテキストスイッチするオーバーヘッドを発生させず
ユーザーモードのままで実現できる機能だからだよ。
ファイルシステムじゃそれは無理。
0348名無しさん＠お腹いっぱい。
垢版 |
2019/11/23(土) 12:24:55.33
zlib 1.2.3より、新しいzlibが必須のソースを野良ビルドするにはどうしたらいいですか？
0349名無しさん＠お腹いっぱい。
垢版 |
2019/11/23(土) 13:58:56.59
zlib を野良ビルドして、OSに影響がない普通は使わないディレクトリ配下に突っ込む。

ソースのビルドのときだけそのディレクトリ配下を読む
スタティックでな

スタティックがダメならそのディレクトリに LD_RUN_PATHあたりを通すしかない
0351名無しさん＠お腹いっぱい。
垢版 |
2019/11/25(月) 07:31:51.97
マヌケな話
current を stable にダウングレード中
libc.so.96.0等、版数が上のものが/usr/lib に入ってる状態でstable を make build したら
libc.so.95.1をつくるんだけど /usr/bin 配下のバイナリは全部 96 とリンクされちゃって失敗w

これらの版数が上のライブラリは ports で入れてるパッケージとの関係ですぐには削除できない

で、

mkdir /usr/temp

cp -v /usr/lib/libc.so.96.0 /usr/temp

echo 'shlib_dirs= /usr/temp ' >> /etc/rc.conf.local

reboot

rm /usr/lib/libc.so.96.0

等として make build

これで ports で入れたパッケージが libc.so.96.0 を使いつつ、make build で libc.so.95.1 をリンクしたrelease 完成
0352名無しさん＠お腹いっぱい。
垢版 |
2019/11/25(月) 07:37:39.04
>>351
これをすると、ports でﾌﾂｰに make しても、/usr/temp 以下を読まないので素直に libc.so.95.1 とリンクする
ボコボコ ports を make し直し中
うぜー

10ヵ月くらい手がかけられなくなるんで stable　に落としてマターリ行く
0354名無しさん＠お腹いっぱい。
垢版 |
2019/11/26(火) 19:36:21.40
OBSDが長い人、教えてくれ。

6.6/packages-stable/amd64

以下の firefox-esr を拾ったら、libc96にリンクされてるんだが、

packages-stable ってそういうディレクトリなのか?
0363名無しさん＠お腹いっぱい。
垢版 |
2019/12/10(火) 12:32:55.21
CVE-2019-19522, is an authentication bypass issue found in the OpenBSD's authentication protocol.
CVE-2019-19520, is a local privilege escalation problem caused by a failed check in xlock.
CVE-2019-19522, the third bug squashed by OpenBSD, is another local privilege escalation problem found in "S/Key" and "YubiKey" functions.
CVE-2019-19519, was found in the "su" function.

だそうな。
これらがsyspatchで出されたみたいだね。
0369名無しさん＠お腹いっぱい。
垢版 |
2019/12/14(土) 20:11:45.53
OpenBSDの起動後、ログイン画面まで進まなくなりました
どうすればログイン画面まで進む状態に戻せますか

（状況）
1. Full Disk Encryption（FDE）されたディスクにOpenBSDをインストールして使っています
2. さきほどOpenBSDを起動してログイン画面まで進んだところで強制終了させました
3. もう一度電源を入れると、FDEのパスワードを入力する画面までは進みました
4. FDEのパスワードを入力しReturnキーを押すと、起動直後の画面に戻ってしまいます
0370名無しさん＠お腹いっぱい。
垢版 |
2019/12/14(土) 20:21:33.60
>>369
> どうすればログイン画面まで進む状態に戻せますか

1. インストール直後にフルバックアップしておいたデータを使って復元する
2. (バックアップがなければ)新規に再インストールする

バックアップを取らなかった時点で負けと考えよう。いい勉強になったね。
0371369
垢版 |
2019/12/14(土) 20:22:56.85
FDEのパスワードを入力してreturnキーを押したあと、起動直後の画面に戻るまでに次のように表示されます

boot>
booting sr0a:/bsd: （省略）
entry point at 0x1001000
0372369
垢版 |
2019/12/14(土) 20:29:41.60
>>370
やはり選択はその2つでしたか
今日の昼までのバックアップデータを別のディスクに復元してみます
起動できなくなったディスクは、今度時間のあるときに外部ディスクとしてbioctlしてみます
0373名無しさん＠お腹いっぱい。
垢版 |
2019/12/14(土) 21:09:51.87
やったことないからただの案だけど、別のディスクとかusbでbootして問題のディスクをfsckするってのは？
0374369
垢版 |
2019/12/15(日) 13:45:34.77
>>373
ありがとうございます
その方法で無事にディスクの内容が読めるようになりました

実施した作業の手順
1. SATA接続用のSSDをUSBで接続できるようにする装置を購入
2. OpenBSDが起動できるパソコンに、起動できなくなったSSD（以外、単に「SSD」と書きます）をUSBで接続
3. bioctlを使い、SSDを復号
4. SSDに対しfsckを実施
5. SSDをマウント
0377名無しさん＠お腹いっぱい。
垢版 |
2019/12/20(金) 20:04:24.21
OpenBSD6.6で
$ pkg_info -Q firefox
としても
firefox-esr-68.2.0
firefox-esr-68.3.0
の2つしか表示されない

でも
$ pkg_add firefox
とするとfirefox-69.0.2p0がインストールできる

なんでですか
0383名無しさん＠お腹いっぱい。
垢版 |
2020/01/14(火) 11:17:25.27
>>361 河豚板のカーネルだけ欲しいってことだよね？ 何が目的？
0390名無しさん＠お腹いっぱい。
垢版 |
2020/01/31(金) 08:36:26.35
こいつはヤバいのでOpenSMTPD使ってるなら即効で当てるように。
当てるまでの間は止めておいた方がいい。
0396名無しさん＠お腹いっぱい。
垢版 |
2020/02/16(日) 03:48:11.83
>>395
AMD64アーキテクチャでは、現状の実装で48ビットのアドレス空間を持ち、256テラバイトまでのメモリを扱うことが出来る。
将来の拡張で4エクサバイトまでの仮想空間をサポートできるようになっている。
0398名無しさん＠お腹いっぱい。
垢版 |
2020/02/25(火) 21:17:16.89
>>6
X1Cに入れるならOpenBSDなのかねえ？
FreeBSDやNetBSDはどない？
0399名無しさん＠お腹いっぱい。
垢版 |
2020/02/26(水) 09:43:53.55
今度もヤバいのでOpenSMTPD使ってるとこは速攻で更新するか
すぐにできないなら更新するまで止めとく必要アリ

ttps://thehackernews.com/2020/02/opensmtpd-email-vulnerability.html

Yet another critical RCE #vulnerability disclosed in #OpenSMTPD email servers running on #OpenBSD or #Linux systems.

The 5-year-old bug could let attackers takeover vulnerable remote servers by sending specially crafted emails.
0403名無しさん＠お腹いっぱい。
垢版 |
2020/03/01(日) 09:58:14.71
>>402
そのスレを立てた者です
マルチポストはすみませんでした
>>398を書いたのも私です
アフィではないです
0405名無しさん＠お腹いっぱい。
垢版 |
2020/03/01(日) 10:56:03.27
>>404
ありがとう
そうしたかったんだけどLinux板だから遠慮した
UNIX板でも立てたいんだけどね
BSDの歴史が好きなんでほんとはノートPCにBSDを入れたかった
0415名無しさん＠お腹いっぱい。
垢版 |
2020/03/21(土) 11:57:41.13
だいぶ前から
pkg_add tor-browser
が失敗する
メンテナに連絡しても返事がないし
0416名無しさん＠お腹いっぱい。
垢版 |
2020/03/27(金) 22:36:21.23
>>415
皆さん、確定申告は無事に終わりましたでしょうか？

私は平成31年からExcelや彌生會計を辞めて、リレーショナルデータベース(MariaDB)で帳簿を付けるようにしました。
無料で使えてサクサク動くのでオススメです。
多少、会計の勉強しないといけませんが、テーブルを作成してしまえば、あとは入力していくだけです。
彌生会計やExcelは重くて使えませんし、クラウド型はセキュリティ上不安なので、OpenBSDをお使いの皆様なら、是非ともMariaDBで帳簿の作成をしてみては如何でしょうか？
新着レスの表示
レスを投稿する

ニューススポーツなんでも実況