OpenBSDユーザーコーナー Part10 (968ﾚｽ)
上下前次1-新
301: 2019/11/11(月)16:53 AAS
>>300
おまえの経営センスなら ubuntu を使うべき
302(1): 2019/11/11(月)17:27 AAS
>>300
>>299
303: 2019/11/11(月)18:22 AAS
Kernel design
by laertes
OpenBSDを使用しているのは短期間なので、この質問が誤った仮定に基づいている場合はご容赦ください。
OpenBSDのカーネル設計は、モノリシックのようです。OpenVMSとNTは、マイクロカーネル
アーキテクチャを使用する2つの著名なオペレーティングシステムです。 マイクロカーネルの
設計は、特権コードが少ないため、根本的に安全であるように思われます。 さらにサーバーの
1つが危殆化した場合でも、被害は最小限に抑えられます。
私の質問は次のとおりです。OpenBSDの設計は基本的に安全ですか、
それとも基本的に欠陥のある設計の非常によくできた実装ですか？
Theo de Raadt:
私はそれは何の違いももたらさないと思います。あなたのコンピューターの先生は
「マイクロカーネル」という言葉が未来のユートピアに関連付けられていた80年代に書かれた本で
教えていたのだと思います。NTはマイクロカーネルであるとは考えていませんが、OpenVMSが
本当にそうだと信じていますか？ マイクロカーネルは、ロード可能なモジュールを通して物事を
行うカーネルではありません。 同様に、システムが本来の役割を果たしている限り、それは
何の違いももたらさないと思います。
304: 2019/11/11(月)18:27 AAS
マイクロカーネルといえばMachだよな
305: 2019/11/11(月)18:44 AAS
果たして経営センスはTheoの言葉を覆す事が可能なのだろうか!?
次回、対決！Theo VS 経営者！！
306(1): 2019/11/11(月)19:39 AAS
何か問題あったらモノリシックカーネルはカーネルごと落ちるんだから堅剛性には欠けるよ
307: 2019/11/11(月)19:42 AAS
経営者ごっこは>>299
308: 2019/11/11(月)19:53 AAS
>>306
OpenBSDがカーネルごと落ちたのを見たことがある人だけがそう言う権利がある。俺はまだ見たことがない。
だが、LinuxがKernel Panicと表示して死んだのは見たことがある。
309(1): 2019/11/12(火)00:19 AAS
じゃkernelpanicが一回でもあれば間違ってるのがopenbsdサイドってことやな
310(1): 2019/11/12(火)07:15 AAS
>>309
もしOpenBSDでKernel Panicが出たとしたら、
・Kernelのバグ
・セキュリティの脆弱性を突かれた結果
のどちらかだろう。原因を追いかけてみないとわからない。
俺はまだ見たことがないので、仮定の話になるが。
それよりLinuxの方がKernel Panic起こす確率が高いことの方が問題だろう。
Linuxはマイクロカーネルでもないし、ユーザー側のアプリを動かすときそのアプリが使うメモリの一部を
カーネル側と共有している。その理由は、カーネルとアプリは頻繁に制御を受け渡ししているが、
その切り替えをシンプル化して少しでも速く動作させるためにわざとそうしている。
だから、アプリが変な死に方をするとカーネルを巻き込んで死ぬことがある。
しかし、これはLinuxの仕様なので変更することができない。
この点、BSD系は律儀に手間をかけてきちんとスイッチしているので多少安心できる。
サーバーで使ったとき、Linuxに比べて死ににくいと言われるのはそのせい。
サーバがおかしくなってもいきなり落ちたり固まったりしないから、データの退避やSyncをしてからシャットダウンできる。
311(1): 2019/11/12(火)08:46 AAS
>>310
vdsoのことなら共有してるメモリーはユーザーランドからはread onlyなのでそうはならんよ。
いい加減な知識で嘘書かない方がいい。
312: 2019/11/12(火)12:24 AAS
Kernel Panicがでるのはドライバが原因なんで、
多くサポートしてるLinuxの方が、それだけ数が多いから出ることが多いってだけ
OpenBSDはドライバ少ないじゃないか。安定というがそれが最新機能に対応してないから
313: 2019/11/12(火)13:43 AAS
ドライバってカーネルの一部だろw
モジュール化されていたとしてもカーネルの一部として機能するんだろw
314(2): 2019/11/12(火)21:35 AAS
使われた結果がフィードバックされる量と直す人の数でLinuxカーネルに勝てない訳で、Windows にも勝てない訳で。
BSD 全般だけど、とても品質がいいわけでは...と思っているけど、品質いいの？
315: 2019/11/12(火)22:10 AAS
>>314
2chｽﾚ:linux
ここで質問すれば優しいお兄さん達が優しく教えてくれる
316(1): 2019/11/12(火)22:54 AAS
>>314
裾野の大きさが違うからね。
ただ人が多いと持ち込まれるモノも多くなってカオスになるというのもある。
痛し痒しだ。
317: 2019/11/12(火)23:27 AAS
2003年のお話
BSD 系 OS と Linux のスケーラビリティについてのベンチマーク
外部ﾘﾝｸ:m.srad.jp
318(1): 2019/11/12(火)23:29 AAS
>>316
Linuxカーネルは今や2100万行だ。まともに保守できるとは思えない。
BSDのように小さければ保守も楽だがこれだけ肥大化するともう手に負えない。
どうなっても誰も責任持てない。
319: 2019/11/12(火)23:41 AAS
カーネルの保守って量の壁はあるけど、そもそも才能ないと無理やんす。（想像です）
320: 2019/11/12(火)23:49 AAS
linuxは2100万行になってもKISSではあるのかね？
321: 2019/11/13(水)01:44 AAS
>>318
君とかオレには無理だと思うが、できる人が世の中にいるのよ
322: 2019/11/13(水)07:06 AAS
ドライバ込みの行数やろ？
コアな部分はそう多くないのでは
323(1): 2019/11/13(水)08:55 AAS
>>311
read onlyにしてもセキュリティの弱さは避けられないみたいだが。
「vDSOは、その制限を克服しながらvsyscall機能を提供するために開発されました。わずか4つのシステムコールを許可する
静的に割り当てられた少量のメモリと、各プロセスで同じアドレスABIを使用すると、セキュリティが低下します。」
324(1): 2019/11/13(水)09:12 AAS
ま、経営責任だよ。
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が効いてるので、その問題は解決されている。
外部ﾘﾝｸ:wiki.ubuntu.com
これはUbuntuの例だが、
grep vdso /proc/*/smaps
とかしてみれば、手元のLinuxでもASLRが効いてることを確認できるぞ。
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ができなくなってセキュリティを弱め、
その判断も誤り。
初期の実装ではASLRに対応してなかったためそういう問題があったが
現在は対応済みのため解決している。
> その代用として仮想システムコールを追加したためにかえって遅くなってしまった。
その判断も誤り。
仮想システムコールって、要はPLT経由の共有ライブラリ関数呼び出しなわけで
オーバーヘッドは libc のシステムコールエントリーポイントを呼ぶのと変わらない。
vDSOなしだと、共有ライブラリ関数呼び出しとシステムコールの両方のオーバーヘッドがあったのが、
vDSOのおかげで、共有ライブラリ関数呼び出しのオーバーヘッドのみに変わり、
純粋に速くなってるわけ。
上下前次1-新書関写板覧索設栞歴
あと 638 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.022s