OpenBSDユーザーコーナー Part10 (951ﾚｽ)
上下前次1-新
325: 2019/11/13(水)13:31 AAS
>>324
つまらない
責任取って辞任しろ
326(1): 2019/11/13(水)13:54 AAS
>>323
そんな日本語にもなってない文章だされても、機械翻訳の誤訳でしょっていう感想にしかならんよ。
意味不明な文章じゃなくて、原文のURLを見せてよ。
327(1): 2019/11/14(木)05:45 AAS
>>326
外部ﾘﾝｸ:en.wikipedia.org
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.
328(1): 2019/11/14(木)08:45 AAS
>>327
やっぱり誤訳だったな。
和訳では少量のメモリーってのがセキュリティを低下させる条件の一つになってるが
原文はそうじゃない。
とはいえ原文もやっぱり意図不明なのでさらにreference
外部ﾘﾝｸ:stackoverflow.com
を辿ると、これはvDSOにASLRが効かないことを問題視してたんだな。
肝心のASLRって単語をに抜いちまうとはwikipediaもひどい。
で、結論を言うとその記述は古い。
以下で分かる通り今ではvDSOにもASLRが効いてるので、その問題は解決されている。
省4
329(1): 2019/11/14(木)18:15 AAS
>>328
いろいろ調べてもらってありがとう。でもこれって結局手間かけて面倒なことをしてるだけだね。
元々vdsoを導入した目的はシステムコールを速く実行するためだったはずなのに、結局目的を達成できてない。
ASLRができなくなってセキュリティを弱め、その代用として仮想システムコールを追加したためにかえって遅くなってしまった。
こんなことなら普通にカーネルランドとユーザーランドを切り替えたほうがよほどシンプルだと思うね。
未確認だけど、もし仮想システムコールが大量に発生するようなプログラムを動かし続けたらいずれカーネル側の
メモリが溢れてmemory overflow起こすなんてことはないだろうね。またセキュリティを気にしないといけなくなる。
カーネル側で仮想システムコールを実行するなんてことしなければこんなことを気にする必要もなかった。
330(1): 2019/11/14(木)18:36 AAS
>>329
なんかまだ大幅に誤解してるみたいね。
> 元々vdsoを導入した目的はシステムコールを速く実行するためだったはずなのに、結局目的を達成できてない。
その判断は誤り。
達成できている。
vDSOなしだとユーザーランドからカーネルにコンテストスイッチして、またユーザーランドに戻る必要がある。
vDSOがあるおかげでコンテストスイッチなしで同じ機能を実現できてる。
> ASLRができなくなってセキュリティを弱め、
省10
331: 2019/11/14(木)18:55 AAS
また経営用語w
332(1): 2019/11/14(木)18:58 AAS
>>330
> vDSOがあるおかげでコンテストスイッチなしで同じ機能を実現できてる。
でも仮想システムコール入れて遅くなってるよね
> 初期の実装ではASLRに対応してなかったためそういう問題があったが
> 現在は対応済みのため解決している。
対応って仮想システムコールでしょ。vDSOでASLRしてるとは書かれてない。
> 仮想システムコールって、要はPLT経由の共有ライブラリ関数呼び出しなわけで
さらっと書いてるけど、vDSOの仮想システムコールがPLT経由で呼び出してるだけというドキュメントはある？
333: 2019/11/14(木)21:22 AAS
>>332
どのシステムコールがvDSOで提供されてるかチェックするだけでも仕組みの想像がつくから調べてみることをお勧めする。
想像つかないならドキュメントなんて読むんじゃなくて
ソースを読む方がいい。
めちゃくちゃ単純な仕組みなんだから。
334: 2019/11/14(木)23:33 AAS
まあ今までの内容で大体はわかったけど、なんか筋が悪い気がする。考え方としてね。
せっかくカーネルをリング0で動かしてセキュリティがっちり守ってるのに、わざわざ共有メモリという抜け穴作って
速くなっただろって言ってる感じ。それで穴ができちゃってまずいことになったから仮想システムコールにしてこれで大丈夫だって。
普通に考えたらリング0とリング3の間でのやりとりが高速になればいいんだからハードでやった方が簡単で安全確実だろう。
CPUのメモリ制御に1個追加機能を持たせてソフトはそれ使うだけでいいようにする。
こうすればどのOSでもこれを利用すればいいから楽だ。
VMwareが出てきたとき、最初は全部ソフトでやってたが、CPUが仮想化技術に対応するようになったら
簡単に仮想化ができるようになった。これと同じ考えでCPUにリング間で安全・高速にメモリ共有する機能を
追加した方がよほど筋がいい。ソフト側で余計なことをしなくて済むしセキュリティも気にしなくて良くなる。
単なる個人的意見だけどね。
335: 2019/11/14(木)23:45 AAS
穴が出るような処理なんてそもそもやってないんだよ。
頭の中で空想するんじゃなくてコード読もうよ。
336(1): 2019/11/19(火)08:29 AAS
ちょっとググっただけでソースは読んでないけどvdsoで実装されてるのってgettimeofdayとかの時間取得系だけなんだよね？
337(1): 2019/11/19(火)08:35 AAS
6.6のTシャツ、良いデザインだよな。
色違いも欲しい。
画像ﾘﾝｸ[jpg]:vangogh.teespring.com
画像ﾘﾝｸ[jpg]:vangogh.teespring.com
画像ﾘﾝｸ[jpg]:vangogh.teespring.com
画像ﾘﾝｸ[jpg]:vangogh.teespring.com
338(1): 2019/11/19(火)12:10 AAS
>>336
x86の場合は時刻取得とgetcpu(3) だけだね。
339: 2019/11/19(火)13:19 AAS
rdate は便利やで
340(1): 2019/11/19(火)18:27 AAS
>>338
時刻取得とかに限定されてるのは統計的に一番呼ばれるシステムコールだからかな？
ファイル関係はvdso化のメリットがないとか？
341: 2019/11/19(火)18:30 AAS
>>340
カーネルモードにコンテキストスイッチするオーバーヘッドを発生させず
ユーザーモードのままで実現できる機能だからだよ。
ファイルシステムじゃそれは無理。
342: 2019/11/19(火)21:21 AAS
>>337
何で邪悪そうなのか
343: 2019/11/20(水)07:41 AAS
赤と黒
ルジェノワール
悪魔の色やで
344(1): 2019/11/20(水)08:33 AAS
つまり daemon ってことですかね。
上下前次1-新書関写板覧索設栞歴
あと 607 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.014s