OpenBSDユーザーコーナー Part10 (968ﾚｽ)
OpenBSDユーザーコーナー Part10 http://mevius.5ch.net/test/read.cgi/unix/1568040383/
上
下
前
次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
323: 名無しさん＠お腹いっぱい。 [sage] 2019/11/13(水) 08:55:54.90 >>311 read onlyにしてもセキュリティの弱さは避けられないみたいだが。 「vDSOは、その制限を克服しながらvsyscall機能を提供するために開発されました。わずか4つのシステムコールを許可する 静的に割り当てられた少量のメモリと、各プロセスで同じアドレスABIを使用すると、セキュリティが低下します。」 http://mevius.5ch.net/test/read.cgi/unix/1568040383/323
324: 名無しさん＠お腹いっぱい。 [sage] 2019/11/13(水) 09:12:36.00 ま、経営責任だよ。 http://mevius.5ch.net/test/read.cgi/unix/1568040383/324
325: 名無しさん＠お腹いっぱい。 [sage] 2019/11/13(水) 13:31:35.95 >>324 つまらない 責任取って辞任しろ http://mevius.5ch.net/test/read.cgi/unix/1568040383/325
326: 名無しさん＠お腹いっぱい。 [sage] 2019/11/13(水) 13:54:37.02 >>323 そんな日本語にもなってない文章だされても、機械翻訳の誤訳でしょっていう感想にしかならんよ。 意味不明な文章じゃなくて、原文のURLを見せてよ。 http://mevius.5ch.net/test/read.cgi/unix/1568040383/326
327: 名無しさん＠お腹いっぱい。 [sage] 2019/11/14(木) 05:45:03.54 >>326 https://en.wikipedia.org/wiki/VDSO vDSO has been developed to offer the vsyscall features while overcoming its limitations: a small amount of statically allocated memory, which allows only 4 system calls, and the same addresses ABI in each process, which compromises security. http://mevius.5ch.net/test/read.cgi/unix/1568040383/327
328: 名無しさん＠お腹いっぱい。 [sage] 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が効いてることを確認できるぞ。 http://mevius.5ch.net/test/read.cgi/unix/1568040383/328
329: 名無しさん＠お腹いっぱい。 [sage] 2019/11/14(木) 18:15:38.54 >>328 いろいろ調べてもらってありがとう。でもこれって結局手間かけて面倒なことをしてるだけだね。 元々vdsoを導入した目的はシステムコールを速く実行するためだったはずなのに、結局目的を達成できてない。 ASLRができなくなってセキュリティを弱め、その代用として仮想システムコールを追加したためにかえって遅くなってしまった。 こんなことなら普通にカーネルランドとユーザーランドを切り替えたほうがよほどシンプルだと思うね。 未確認だけど、もし仮想システムコールが大量に発生するようなプログラムを動かし続けたらいずれカーネル側の メモリが溢れてmemory overflow起こすなんてことはないだろうね。またセキュリティを気にしないといけなくなる。 カーネル側で仮想システムコールを実行するなんてことしなければこんなことを気にする必要もなかった。 http://mevius.5ch.net/test/read.cgi/unix/1568040383/329
330: 名無しさん＠お腹いっぱい。 [sage] 2019/11/14(木) 18:36:16.61 >>329 なんかまだ大幅に誤解してるみたいね。 > 元々vdsoを導入した目的はシステムコールを速く実行するためだったはずなのに、結局目的を達成できてない。 その判断は誤り。 達成できている。 vDSOなしだとユーザーランドからカーネルにコンテストスイッチして、またユーザーランドに戻る必要がある。 vDSOがあるおかげでコンテストスイッチなしで同じ機能を実現できてる。 > ASLRができなくなってセキュリティを弱め、 その判断も誤り。 初期の実装ではASLRに対応してなかったためそういう問題があったが 現在は対応済みのため解決している。 > その代用として仮想システムコールを追加したためにかえって遅くなってしまった。 その判断も誤り。 仮想システムコールって、要はPLT経由の共有ライブラリ関数呼び出しなわけで オーバーヘッドは libc のシステムコールエントリーポイントを呼ぶのと変わらない。 vDSOなしだと、共有ライブラリ関数呼び出しとシステムコールの両方のオーバーヘッドがあったのが、 vDSOのおかげで、共有ライブラリ関数呼び出しのオーバーヘッドのみに変わり、 純粋に速くなってるわけ。 http://mevius.5ch.net/test/read.cgi/unix/1568040383/330
331: 名無しさん＠お腹いっぱい。 [sage] 2019/11/14(木) 18:55:39.79 また経営用語w http://mevius.5ch.net/test/read.cgi/unix/1568040383/331
332: 名無しさん＠お腹いっぱい。 [sage] 2019/11/14(木) 18:58:36.32 >>330 > vDSOがあるおかげでコンテストスイッチなしで同じ機能を実現できてる。 でも仮想システムコール入れて遅くなってるよね > 初期の実装ではASLRに対応してなかったためそういう問題があったが > 現在は対応済みのため解決している。 対応って仮想システムコールでしょ。vDSOでASLRしてるとは書かれてない。 > 仮想システムコールって、要はPLT経由の共有ライブラリ関数呼び出しなわけで さらっと書いてるけど、vDSOの仮想システムコールがPLT経由で呼び出してるだけというドキュメントはある？ http://mevius.5ch.net/test/read.cgi/unix/1568040383/332
333: 名無しさん＠お腹いっぱい。 [sage] 2019/11/14(木) 21:22:31.61 >>332 どのシステムコールがvDSOで提供されてるかチェックするだけでも仕組みの想像がつくから調べてみることをお勧めする。 想像つかないならドキュメントなんて読むんじゃなくて ソースを読む方がいい。 めちゃくちゃ単純な仕組みなんだから。 http://mevius.5ch.net/test/read.cgi/unix/1568040383/333
334: 名無しさん＠お腹いっぱい。 [sage] 2019/11/14(木) 23:33:45.55 まあ今までの内容で大体はわかったけど、なんか筋が悪い気がする。考え方としてね。 せっかくカーネルをリング0で動かしてセキュリティがっちり守ってるのに、わざわざ共有メモリという抜け穴作って 速くなっただろって言ってる感じ。それで穴ができちゃってまずいことになったから仮想システムコールにしてこれで大丈夫だって。 普通に考えたらリング0とリング3の間でのやりとりが高速になればいいんだからハードでやった方が簡単で安全確実だろう。 CPUのメモリ制御に1個追加機能を持たせてソフトはそれ使うだけでいいようにする。 こうすればどのOSでもこれを利用すればいいから楽だ。 VMwareが出てきたとき、最初は全部ソフトでやってたが、CPUが仮想化技術に対応するようになったら 簡単に仮想化ができるようになった。これと同じ考えでCPUにリング間で安全・高速にメモリ共有する機能を 追加した方がよほど筋がいい。ソフト側で余計なことをしなくて済むしセキュリティも気にしなくて良くなる。 単なる個人的意見だけどね。 http://mevius.5ch.net/test/read.cgi/unix/1568040383/334
335: 名無しさん＠お腹いっぱい。 [sage] 2019/11/14(木) 23:45:34.54 穴が出るような処理なんてそもそもやってないんだよ。 頭の中で空想するんじゃなくてコード読もうよ。 http://mevius.5ch.net/test/read.cgi/unix/1568040383/335
336: 名無しさん＠お腹いっぱい。 [sage] 2019/11/19(火) 08:29:11.50 ちょっとググっただけでソースは読んでないけどvdsoで実装されてるのってgettimeofdayとかの時間取得系だけなんだよね？ http://mevius.5ch.net/test/read.cgi/unix/1568040383/336
337: 名無しさん＠お腹いっぱい。 [sage] 2019/11/19(火) 08:35:47.72 6.6のTシャツ、良いデザインだよな。 色違いも欲しい。 https://vangogh.teespring.com/v3/image/-ehuDh9YKplWJNvmeJdWLyiYMS4/480/560.jpg https://vangogh.teespring.com/v3/image/qsJyRhyjEdJM3x917KoDv2DXmCY/480/560.jpg https://vangogh.teespring.com/v3/image/1g6MQmDWY6sYbgShLPynjqwiY9k/480/560.jpg https://vangogh.teespring.com/v3/image/rqRo3NyUtZJytjXxrT6xOKX6xfQ/480/560.jpg http://mevius.5ch.net/test/read.cgi/unix/1568040383/337
338: 名無しさん＠お腹いっぱい。 [sage] 2019/11/19(火) 12:10:43.37 >>336 x86の場合は時刻取得とgetcpu(3) だけだね。 http://mevius.5ch.net/test/read.cgi/unix/1568040383/338
339: 名無しさん＠お腹いっぱい。 [sage] 2019/11/19(火) 13:19:19.32 rdate は便利やで http://mevius.5ch.net/test/read.cgi/unix/1568040383/339
340: 名無しさん＠お腹いっぱい。 [sage] 2019/11/19(火) 18:27:00.42 >>338 時刻取得とかに限定されてるのは統計的に一番呼ばれるシステムコールだからかな？ ファイル関係はvdso化のメリットがないとか？ http://mevius.5ch.net/test/read.cgi/unix/1568040383/340
341: 名無しさん＠お腹いっぱい。 [sage] 2019/11/19(火) 18:30:50.49 >>340 カーネルモードにコンテキストスイッチするオーバーヘッドを発生させず ユーザーモードのままで実現できる機能だからだよ。 ファイルシステムじゃそれは無理。 http://mevius.5ch.net/test/read.cgi/unix/1568040383/341
342: 名無しさん＠お腹いっぱい。 [sage] 2019/11/19(火) 21:21:32.14 >>337 何で邪悪そうなのか http://mevius.5ch.net/test/read.cgi/unix/1568040383/342
343: 名無しさん＠お腹いっぱい。 [sage] 2019/11/20(水) 07:41:53.66 赤と黒 ルジェノワール 悪魔の色やで http://mevius.5ch.net/test/read.cgi/unix/1568040383/343
344: 名無しさん＠お腹いっぱい。 [sage] 2019/11/20(水) 08:33:03.54 つまり daemon ってことですかね。 http://mevius.5ch.net/test/read.cgi/unix/1568040383/344
345: 名無しさん＠お腹いっぱい。 [sage] 2019/11/20(水) 12:00:30.01 あれ、セキュリティパッチ入ってたね… http://mevius.5ch.net/test/read.cgi/unix/1568040383/345
346: 名無しさん＠お腹いっぱい。 [sage] 2019/11/20(水) 12:09:13.02 + if (ni->ni_chan != IEEE80211_CHAN_ANYC) + nr->nr_chan_flags = ni->ni_chan->ic_flags; 2ちゃんパッチ… http://mevius.5ch.net/test/read.cgi/unix/1568040383/346
347: 名無しさん＠お腹いっぱい。 [sage] 2019/11/22(金) 18:52:41.60 texlive が 20190410 になったで http://mevius.5ch.net/test/read.cgi/unix/1568040383/347
348: 名無しさん＠お腹いっぱい。 [] 2019/11/23(土) 12:24:55.33 zlib 1.2.3より、新しいzlibが必須のソースを野良ビルドするにはどうしたらいいですか？ http://mevius.5ch.net/test/read.cgi/unix/1568040383/348
349: 名無しさん＠お腹いっぱい。 [sage] 2019/11/23(土) 13:58:56.59 zlib を野良ビルドして、OSに影響がない普通は使わないディレクトリ配下に突っ込む。 ソースのビルドのときだけそのディレクトリ配下を読む スタティックでな スタティックがダメならそのディレクトリに LD_RUN_PATHあたりを通すしかない http://mevius.5ch.net/test/read.cgi/unix/1568040383/349
350: 名無しさん＠お腹いっぱい。 [sage] 2019/11/23(土) 14:00:55.67 自分がやってるのは、そういうソースとzlibを $HOME/tools に突っ込んじゃう。 http://mevius.5ch.net/test/read.cgi/unix/1568040383/350
351: 名無しさん＠お腹いっぱい。 [sage] 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 完成 http://mevius.5ch.net/test/read.cgi/unix/1568040383/351
352: 名無しさん＠お腹いっぱい。 [sage] 2019/11/25(月) 07:37:39.04 >>351 これをすると、ports でﾌﾂｰに make しても、/usr/temp 以下を読まないので素直に libc.so.95.1 とリンクする ボコボコ ports を make し直し中 うぜー 10ヵ月くらい手がかけられなくなるんで stable に落としてマターリ行く http://mevius.5ch.net/test/read.cgi/unix/1568040383/352
ﾒﾓ帳
(0/65535文字)
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
あと 616 ﾚｽあります
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.012s