OpenBSDユーザーコーナー Part10 (951ﾚｽ)
OpenBSDユーザーコーナー Part10 http://mevius.5ch.net/test/read.cgi/unix/1568040383/
上
下
前
次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
317: 名無しさん＠お腹いっぱい。 [sage] 2019/11/12(火) 23:27:53.96 2003年のお話 BSD 系 OS と Linux のスケーラビリティについてのベンチマーク https://m.srad.jp/story/03/10/19/2035242 http://mevius.5ch.net/test/read.cgi/unix/1568040383/317
318: 名無しさん＠お腹いっぱい。 [sage] 2019/11/12(火) 23:29:58.94 >>316 Linuxカーネルは今や2100万行だ。まともに保守できるとは思えない。 BSDのように小さければ保守も楽だがこれだけ肥大化するともう手に負えない。 どうなっても誰も責任持てない。 http://mevius.5ch.net/test/read.cgi/unix/1568040383/318
319: 名無しさん＠お腹いっぱい。 [sage] 2019/11/12(火) 23:41:49.79 カーネルの保守って量の壁はあるけど、そもそも才能ないと無理やんす。（想像です） http://mevius.5ch.net/test/read.cgi/unix/1568040383/319
320: 名無しさん＠お腹いっぱい。 [sage] 2019/11/12(火) 23:49:09.61 linuxは2100万行になってもKISSではあるのかね？ http://mevius.5ch.net/test/read.cgi/unix/1568040383/320
321: 名無しさん＠お腹いっぱい。 [sage] 2019/11/13(水) 01:44:41.11 >>318 君とかオレには無理だと思うが、できる人が世の中にいるのよ http://mevius.5ch.net/test/read.cgi/unix/1568040383/321
322: 名無しさん＠お腹いっぱい。 [] 2019/11/13(水) 07:06:34.38 ドライバ込みの行数やろ？ コアな部分はそう多くないのでは http://mevius.5ch.net/test/read.cgi/unix/1568040383/322
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
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
あと 615 ﾚｽあります
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.009s