OpenBSD についてまったり語るスレ。
https://www.openbsd.org/
探検
OpenBSDユーザーコーナー Part10
2019/09/09(月) 23:46:23.19
2019/11/10(日) 19:25:50.77
そこを「えっ」とかで自分は分かってるんだけど感だけ出して何も答えてないってのはどうなのよ？
2019/11/10(日) 20:09:14.50
モノシリックカーネル
2019/11/10(日) 20:28:55.39
>>288
全然物知りじゃないなw
全然物知りじゃないなw
2019/11/11(月) 03:03:16.85
>>285
マイクロカーネルにすると何が嬉しいの？
マイクロカーネルにすると何が嬉しいの？
2019/11/11(月) 04:05:33.10
セキュリティが堅剛になる
2019/11/11(月) 04:27:21.14
>>291
どういう理屈で？
どういう理屈で？
2019/11/11(月) 06:04:56.61
294名無しさん＠お腹いっぱい。
2019/11/11(月) 07:30:33.33 >>285
マイクロカーネルを採用するとセキュリティが堅牢になる理由を30字以内で述べよ
マイクロカーネルを採用するとセキュリティが堅牢になる理由を30字以内で述べよ
2019/11/11(月) 10:34:05.38
>>294
小市民の分際で世に意見するのは100年早い
小市民の分際で世に意見するのは100年早い
2019/11/11(月) 13:21:53.08
2019/11/11(月) 15:32:11.30
>>294
https://ja.wikipedia.org/wiki/DragonFly_BSD#%E3%82%AB%E3%83%BC%E3%83%8D%E3%83%AB%E3%81%AE%E8%A8%AD%E8%A8%88
DragonFly BSDには、最近の殆どのカーネルのように、ハイブリッドカーネルが採用されている。つまり、これは、モノリシックカーネルと
マイクロカーネルの両方の性質を併せ持ち、必要に応じて両方のメリットを使うということである。例えば、マイクロカーネルのメッセージシステムに
あるようなメモリ保護の恩恵を受けるのと同時に、モノリシックカーネルにあるような処理速度は残っている。
メッセージサブシステムは、Machのようなマイクロカーネルのデザインと似て、余り複雑ではないものになっている。
さらに、これは同期通信と非同期通信の両方に対応しており、状況に応じて最良の性能を出せるようになっている。
https://ja.wikipedia.org/wiki/DragonFly_BSD#%E3%82%AB%E3%83%BC%E3%83%8D%E3%83%AB%E3%81%AE%E8%A8%AD%E8%A8%88
DragonFly BSDには、最近の殆どのカーネルのように、ハイブリッドカーネルが採用されている。つまり、これは、モノリシックカーネルと
マイクロカーネルの両方の性質を併せ持ち、必要に応じて両方のメリットを使うということである。例えば、マイクロカーネルのメッセージシステムに
あるようなメモリ保護の恩恵を受けるのと同時に、モノリシックカーネルにあるような処理速度は残っている。
メッセージサブシステムは、Machのようなマイクロカーネルのデザインと似て、余り複雑ではないものになっている。
さらに、これは同期通信と非同期通信の両方に対応しており、状況に応じて最良の性能を出せるようになっている。
2019/11/11(月) 16:18:24.21
最良の性能がセキュリティ
これが経営センスだ
これが経営センスだ
2019/11/11(月) 16:30:46.00
続きはこちらで
知ったかぶりしてＬＩＮＵＸを語るスレ [無断転載禁止]©2ch.net
https://mao.5ch.net/test/read.cgi/linux/1471167085/
知ったかぶりしてＬＩＮＵＸを語るスレ [無断転載禁止]©2ch.net
https://mao.5ch.net/test/read.cgi/linux/1471167085/
2019/11/11(月) 16:35:51.28
openbsdを使ってる人っているの？
別に早いわけでもないしアプリ入れたらセキュリティも他と変わらんし
別に早いわけでもないしアプリ入れたらセキュリティも他と変わらんし
2019/11/11(月) 16:53:38.52
>>300
おまえの経営センスなら ubuntu を使うべき
おまえの経営センスなら ubuntu を使うべき
2019/11/11(月) 17:27:30.87
303名無しさん＠お腹いっぱい。
2019/11/11(月) 18:22:13.31 Kernel design
by laertes
OpenBSDを使用しているのは短期間なので、この質問が誤った仮定に基づいている場合はご容赦ください。
OpenBSDのカーネル設計は、モノリシックのようです。OpenVMSとNTは、マイクロカーネル
アーキテクチャを使用する2つの著名なオペレーティングシステムです。 マイクロカーネルの
設計は、特権コードが少ないため、根本的に安全であるように思われます。 さらにサーバーの
1つが危殆化した場合でも、被害は最小限に抑えられます。
私の質問は次のとおりです。OpenBSDの設計は基本的に安全ですか、
それとも基本的に欠陥のある設計の非常によくできた実装ですか？
Theo de Raadt:
私はそれは何の違いももたらさないと思います。あなたのコンピューターの先生は
「マイクロカーネル」という言葉が未来のユートピアに関連付けられていた80年代に書かれた本で
教えていたのだと思います。NTはマイクロカーネルであるとは考えていませんが、OpenVMSが
本当にそうだと信じていますか？ マイクロカーネルは、ロード可能なモジュールを通して物事を
行うカーネルではありません。 同様に、システムが本来の役割を果たしている限り、それは
何の違いももたらさないと思います。
by laertes
OpenBSDを使用しているのは短期間なので、この質問が誤った仮定に基づいている場合はご容赦ください。
OpenBSDのカーネル設計は、モノリシックのようです。OpenVMSとNTは、マイクロカーネル
アーキテクチャを使用する2つの著名なオペレーティングシステムです。 マイクロカーネルの
設計は、特権コードが少ないため、根本的に安全であるように思われます。 さらにサーバーの
1つが危殆化した場合でも、被害は最小限に抑えられます。
私の質問は次のとおりです。OpenBSDの設計は基本的に安全ですか、
それとも基本的に欠陥のある設計の非常によくできた実装ですか？
Theo de Raadt:
私はそれは何の違いももたらさないと思います。あなたのコンピューターの先生は
「マイクロカーネル」という言葉が未来のユートピアに関連付けられていた80年代に書かれた本で
教えていたのだと思います。NTはマイクロカーネルであるとは考えていませんが、OpenVMSが
本当にそうだと信じていますか？ マイクロカーネルは、ロード可能なモジュールを通して物事を
行うカーネルではありません。 同様に、システムが本来の役割を果たしている限り、それは
何の違いももたらさないと思います。
2019/11/11(月) 18:27:55.12
マイクロカーネルといえばMachだよな
2019/11/11(月) 18:44:35.98
果たして経営センスはTheoの言葉を覆す事が可能なのだろうか!?
次回、対決！Theo VS 経営者！！
次回、対決！Theo VS 経営者！！
2019/11/11(月) 19:39:23.99
何か問題あったらモノリシックカーネルはカーネルごと落ちるんだから堅剛性には欠けるよ
2019/11/11(月) 19:42:56.22
経営者ごっこは>>299
2019/11/11(月) 19:53:53.33
309名無しさん＠お腹いっぱい。
2019/11/12(火) 00:19:10.51 じゃkernelpanicが一回でもあれば間違ってるのがopenbsdサイドってことやな
2019/11/12(火) 07:15:51.71
>>309
もしOpenBSDでKernel Panicが出たとしたら、
・Kernelのバグ
・セキュリティの脆弱性を突かれた結果
のどちらかだろう。原因を追いかけてみないとわからない。
俺はまだ見たことがないので、仮定の話になるが。
それよりLinuxの方がKernel Panic起こす確率が高いことの方が問題だろう。
Linuxはマイクロカーネルでもないし、ユーザー側のアプリを動かすときそのアプリが使うメモリの一部を
カーネル側と共有している。その理由は、カーネルとアプリは頻繁に制御を受け渡ししているが、
その切り替えをシンプル化して少しでも速く動作させるためにわざとそうしている。
だから、アプリが変な死に方をするとカーネルを巻き込んで死ぬことがある。
しかし、これはLinuxの仕様なので変更することができない。
この点、BSD系は律儀に手間をかけてきちんとスイッチしているので多少安心できる。
サーバーで使ったとき、Linuxに比べて死ににくいと言われるのはそのせい。
サーバがおかしくなってもいきなり落ちたり固まったりしないから、データの退避やSyncをしてからシャットダウンできる。
もしOpenBSDでKernel Panicが出たとしたら、
・Kernelのバグ
・セキュリティの脆弱性を突かれた結果
のどちらかだろう。原因を追いかけてみないとわからない。
俺はまだ見たことがないので、仮定の話になるが。
それよりLinuxの方がKernel Panic起こす確率が高いことの方が問題だろう。
Linuxはマイクロカーネルでもないし、ユーザー側のアプリを動かすときそのアプリが使うメモリの一部を
カーネル側と共有している。その理由は、カーネルとアプリは頻繁に制御を受け渡ししているが、
その切り替えをシンプル化して少しでも速く動作させるためにわざとそうしている。
だから、アプリが変な死に方をするとカーネルを巻き込んで死ぬことがある。
しかし、これはLinuxの仕様なので変更することができない。
この点、BSD系は律儀に手間をかけてきちんとスイッチしているので多少安心できる。
サーバーで使ったとき、Linuxに比べて死ににくいと言われるのはそのせい。
サーバがおかしくなってもいきなり落ちたり固まったりしないから、データの退避やSyncをしてからシャットダウンできる。
2019/11/12(火) 08:46:06.85
2019/11/12(火) 12:24:15.93
Kernel Panicがでるのはドライバが原因なんで、
多くサポートしてるLinuxの方が、それだけ数が多いから出ることが多いってだけ
OpenBSDはドライバ少ないじゃないか。安定というがそれが最新機能に対応してないから
多くサポートしてるLinuxの方が、それだけ数が多いから出ることが多いってだけ
OpenBSDはドライバ少ないじゃないか。安定というがそれが最新機能に対応してないから
2019/11/12(火) 13:43:54.52
ドライバってカーネルの一部だろw
モジュール化されていたとしてもカーネルの一部として機能するんだろw
モジュール化されていたとしてもカーネルの一部として機能するんだろw
2019/11/12(火) 21:35:18.50
使われた結果がフィードバックされる量と直す人の数でLinuxカーネルに勝てない訳で、Windows にも勝てない訳で。
BSD 全般だけど、とても品質がいいわけでは...と思っているけど、品質いいの？
BSD 全般だけど、とても品質がいいわけでは...と思っているけど、品質いいの？
2019/11/12(火) 22:10:29.76
2019/11/12(火) 22:54:03.68
2019/11/12(火) 23:27:53.96
2019/11/12(火) 23:29:58.94
2019/11/12(火) 23:41:49.79
カーネルの保守って量の壁はあるけど、そもそも才能ないと無理やんす。（想像です）
2019/11/12(火) 23:49:09.61
linuxは2100万行になってもKISSではあるのかね？
2019/11/13(水) 01:44:41.11
>>318
君とかオレには無理だと思うが、できる人が世の中にいるのよ
君とかオレには無理だと思うが、できる人が世の中にいるのよ
322名無しさん＠お腹いっぱい。
2019/11/13(水) 07:06:34.38 ドライバ込みの行数やろ？
コアな部分はそう多くないのでは
コアな部分はそう多くないのでは
2019/11/13(水) 08:55:54.90
>>311
read onlyにしてもセキュリティの弱さは避けられないみたいだが。
「vDSOは、その制限を克服しながらvsyscall機能を提供するために開発されました。わずか4つのシステムコールを許可する
静的に割り当てられた少量のメモリと、各プロセスで同じアドレスABIを使用すると、セキュリティが低下します。」
read onlyにしてもセキュリティの弱さは避けられないみたいだが。
「vDSOは、その制限を克服しながらvsyscall機能を提供するために開発されました。わずか4つのシステムコールを許可する
静的に割り当てられた少量のメモリと、各プロセスで同じアドレスABIを使用すると、セキュリティが低下します。」
2019/11/13(水) 09:12:36.00
ま、経営責任だよ。
2019/11/13(水) 13:31:35.95
2019/11/13(水) 13:54:37.02
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.
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.
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が効いてることを確認できるぞ。
やっぱり誤訳だったな。
和訳では少量のメモリーってのがセキュリティを低下させる条件の一つになってるが
原文はそうじゃない。
とはいえ原文もやっぱり意図不明なのでさらに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が効いてることを確認できるぞ。
2019/11/14(木) 18:15:38.54
>>328
いろいろ調べてもらってありがとう。でもこれって結局手間かけて面倒なことをしてるだけだね。
元々vdsoを導入した目的はシステムコールを速く実行するためだったはずなのに、結局目的を達成できてない。
ASLRができなくなってセキュリティを弱め、その代用として仮想システムコールを追加したためにかえって遅くなってしまった。
こんなことなら普通にカーネルランドとユーザーランドを切り替えたほうがよほどシンプルだと思うね。
未確認だけど、もし仮想システムコールが大量に発生するようなプログラムを動かし続けたらいずれカーネル側の
メモリが溢れてmemory overflow起こすなんてことはないだろうね。またセキュリティを気にしないといけなくなる。
カーネル側で仮想システムコールを実行するなんてことしなければこんなことを気にする必要もなかった。
いろいろ調べてもらってありがとう。でもこれって結局手間かけて面倒なことをしてるだけだね。
元々vdsoを導入した目的はシステムコールを速く実行するためだったはずなのに、結局目的を達成できてない。
ASLRができなくなってセキュリティを弱め、その代用として仮想システムコールを追加したためにかえって遅くなってしまった。
こんなことなら普通にカーネルランドとユーザーランドを切り替えたほうがよほどシンプルだと思うね。
未確認だけど、もし仮想システムコールが大量に発生するようなプログラムを動かし続けたらいずれカーネル側の
メモリが溢れてmemory overflow起こすなんてことはないだろうね。またセキュリティを気にしないといけなくなる。
カーネル側で仮想システムコールを実行するなんてことしなければこんなことを気にする必要もなかった。
2019/11/14(木) 18:36:16.61
>>329
なんかまだ大幅に誤解してるみたいね。
> 元々vdsoを導入した目的はシステムコールを速く実行するためだったはずなのに、結局目的を達成できてない。
その判断は誤り。
達成できている。
vDSOなしだとユーザーランドからカーネルにコンテストスイッチして、またユーザーランドに戻る必要がある。
vDSOがあるおかげでコンテストスイッチなしで同じ機能を実現できてる。
> ASLRができなくなってセキュリティを弱め、
その判断も誤り。
初期の実装ではASLRに対応してなかったためそういう問題があったが
現在は対応済みのため解決している。
> その代用として仮想システムコールを追加したためにかえって遅くなってしまった。
その判断も誤り。
仮想システムコールって、要はPLT経由の共有ライブラリ関数呼び出しなわけで
オーバーヘッドは libc のシステムコールエントリーポイントを呼ぶのと変わらない。
vDSOなしだと、共有ライブラリ関数呼び出しとシステムコールの両方のオーバーヘッドがあったのが、
vDSOのおかげで、共有ライブラリ関数呼び出しのオーバーヘッドのみに変わり、
純粋に速くなってるわけ。
なんかまだ大幅に誤解してるみたいね。
> 元々vdsoを導入した目的はシステムコールを速く実行するためだったはずなのに、結局目的を達成できてない。
その判断は誤り。
達成できている。
vDSOなしだとユーザーランドからカーネルにコンテストスイッチして、またユーザーランドに戻る必要がある。
vDSOがあるおかげでコンテストスイッチなしで同じ機能を実現できてる。
> ASLRができなくなってセキュリティを弱め、
その判断も誤り。
初期の実装ではASLRに対応してなかったためそういう問題があったが
現在は対応済みのため解決している。
> その代用として仮想システムコールを追加したためにかえって遅くなってしまった。
その判断も誤り。
仮想システムコールって、要はPLT経由の共有ライブラリ関数呼び出しなわけで
オーバーヘッドは libc のシステムコールエントリーポイントを呼ぶのと変わらない。
vDSOなしだと、共有ライブラリ関数呼び出しとシステムコールの両方のオーバーヘッドがあったのが、
vDSOのおかげで、共有ライブラリ関数呼び出しのオーバーヘッドのみに変わり、
純粋に速くなってるわけ。
2019/11/14(木) 18:55:39.79
また経営用語w
2019/11/14(木) 18:58:36.32
>>330
> vDSOがあるおかげでコンテストスイッチなしで同じ機能を実現できてる。
でも仮想システムコール入れて遅くなってるよね
> 初期の実装ではASLRに対応してなかったためそういう問題があったが
> 現在は対応済みのため解決している。
対応って仮想システムコールでしょ。vDSOでASLRしてるとは書かれてない。
> 仮想システムコールって、要はPLT経由の共有ライブラリ関数呼び出しなわけで
さらっと書いてるけど、vDSOの仮想システムコールがPLT経由で呼び出してるだけというドキュメントはある？
> vDSOがあるおかげでコンテストスイッチなしで同じ機能を実現できてる。
でも仮想システムコール入れて遅くなってるよね
> 初期の実装ではASLRに対応してなかったためそういう問題があったが
> 現在は対応済みのため解決している。
対応って仮想システムコールでしょ。vDSOでASLRしてるとは書かれてない。
> 仮想システムコールって、要はPLT経由の共有ライブラリ関数呼び出しなわけで
さらっと書いてるけど、vDSOの仮想システムコールがPLT経由で呼び出してるだけというドキュメントはある？
2019/11/14(木) 21:22:31.61
>>332
どのシステムコールがvDSOで提供されてるかチェックするだけでも仕組みの想像がつくから調べてみることをお勧めする。
想像つかないならドキュメントなんて読むんじゃなくて
ソースを読む方がいい。
めちゃくちゃ単純な仕組みなんだから。
どのシステムコールがvDSOで提供されてるかチェックするだけでも仕組みの想像がつくから調べてみることをお勧めする。
想像つかないならドキュメントなんて読むんじゃなくて
ソースを読む方がいい。
めちゃくちゃ単純な仕組みなんだから。
2019/11/14(木) 23:33:45.55
まあ今までの内容で大体はわかったけど、なんか筋が悪い気がする。考え方としてね。
せっかくカーネルをリング0で動かしてセキュリティがっちり守ってるのに、わざわざ共有メモリという抜け穴作って
速くなっただろって言ってる感じ。それで穴ができちゃってまずいことになったから仮想システムコールにしてこれで大丈夫だって。
普通に考えたらリング0とリング3の間でのやりとりが高速になればいいんだからハードでやった方が簡単で安全確実だろう。
CPUのメモリ制御に1個追加機能を持たせてソフトはそれ使うだけでいいようにする。
こうすればどのOSでもこれを利用すればいいから楽だ。
VMwareが出てきたとき、最初は全部ソフトでやってたが、CPUが仮想化技術に対応するようになったら
簡単に仮想化ができるようになった。これと同じ考えでCPUにリング間で安全・高速にメモリ共有する機能を
追加した方がよほど筋がいい。ソフト側で余計なことをしなくて済むしセキュリティも気にしなくて良くなる。
単なる個人的意見だけどね。
せっかくカーネルをリング0で動かしてセキュリティがっちり守ってるのに、わざわざ共有メモリという抜け穴作って
速くなっただろって言ってる感じ。それで穴ができちゃってまずいことになったから仮想システムコールにしてこれで大丈夫だって。
普通に考えたらリング0とリング3の間でのやりとりが高速になればいいんだからハードでやった方が簡単で安全確実だろう。
CPUのメモリ制御に1個追加機能を持たせてソフトはそれ使うだけでいいようにする。
こうすればどのOSでもこれを利用すればいいから楽だ。
VMwareが出てきたとき、最初は全部ソフトでやってたが、CPUが仮想化技術に対応するようになったら
簡単に仮想化ができるようになった。これと同じ考えでCPUにリング間で安全・高速にメモリ共有する機能を
追加した方がよほど筋がいい。ソフト側で余計なことをしなくて済むしセキュリティも気にしなくて良くなる。
単なる個人的意見だけどね。
2019/11/14(木) 23:45:34.54
穴が出るような処理なんてそもそもやってないんだよ。
頭の中で空想するんじゃなくてコード読もうよ。
頭の中で空想するんじゃなくてコード読もうよ。
2019/11/19(火) 08:29:11.50
ちょっとググっただけでソースは読んでないけどvdsoで実装されてるのってgettimeofdayとかの時間取得系だけなんだよね？
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
色違いも欲しい。
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
2019/11/19(火) 12:10:43.37
>>336
x86の場合は時刻取得とgetcpu(3) だけだね。
x86の場合は時刻取得とgetcpu(3) だけだね。
2019/11/19(火) 13:19:19.32
rdate は便利やで
2019/11/19(火) 18:27:00.42
2019/11/19(火) 18:30:50.49
2019/11/19(火) 21:21:32.14
>>337
何で邪悪そうなのか
何で邪悪そうなのか
2019/11/20(水) 07:41:53.66
赤と黒
ルジェノワール
悪魔の色やで
ルジェノワール
悪魔の色やで
2019/11/20(水) 08:33:03.54
つまり daemon ってことですかね。
2019/11/20(水) 12:00:30.01
あれ、セキュリティパッチ入ってたね…
2019/11/20(水) 12:09:13.02
+ if (ni->ni_chan != IEEE80211_CHAN_ANYC)
+ nr->nr_chan_flags = ni->ni_chan->ic_flags;
2ちゃんパッチ…
+ nr->nr_chan_flags = ni->ni_chan->ic_flags;
2ちゃんパッチ…
2019/11/22(金) 18:52:41.60
texlive が 20190410 になったで
348名無しさん＠お腹いっぱい。
2019/11/23(土) 12:24:55.33 zlib 1.2.3より、新しいzlibが必須のソースを野良ビルドするにはどうしたらいいですか？
2019/11/23(土) 13:58:56.59
zlib を野良ビルドして、OSに影響がない普通は使わないディレクトリ配下に突っ込む。
ソースのビルドのときだけそのディレクトリ配下を読む
スタティックでな
スタティックがダメならそのディレクトリに LD_RUN_PATHあたりを通すしかない
ソースのビルドのときだけそのディレクトリ配下を読む
スタティックでな
スタティックがダメならそのディレクトリに LD_RUN_PATHあたりを通すしかない
2019/11/23(土) 14:00:55.67
自分がやってるのは、そういうソースとzlibを $HOME/tools に突っ込んじゃう。
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 完成
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 完成
2019/11/25(月) 07:37:39.04
>>351
これをすると、ports でﾌﾂｰに make しても、/usr/temp 以下を読まないので素直に libc.so.95.1 とリンクする
ボコボコ ports を make し直し中
うぜー
10ヵ月くらい手がかけられなくなるんで stable に落としてマターリ行く
これをすると、ports でﾌﾂｰに make しても、/usr/temp 以下を読まないので素直に libc.so.95.1 とリンクする
ボコボコ ports を make し直し中
うぜー
10ヵ月くらい手がかけられなくなるんで stable に落としてマターリ行く
2019/11/26(火) 01:51:36.01
2019/11/26(火) 19:36:21.40
OBSDが長い人、教えてくれ。
6.6/packages-stable/amd64
以下の firefox-esr を拾ったら、libc96にリンクされてるんだが、
packages-stable ってそういうディレクトリなのか?
6.6/packages-stable/amd64
以下の firefox-esr を拾ったら、libc96にリンクされてるんだが、
packages-stable ってそういうディレクトリなのか?
2019/11/26(火) 20:10:31.36
2019/12/08(日) 07:44:12.38
凄いところにセキュリティパッチ入ってるね
2019/12/08(日) 09:31:01.76
影響範囲広い。
これっていつからあったの？
これっていつからあったの？
2019/12/09(月) 08:26:43.95
認証のヤツ？
2019/12/09(月) 08:30:26.15
>>358
そう
そう
2019/12/09(月) 09:47:40.39
また入ってるよ > 012
2019/12/09(月) 17:54:39.69
こんなところでｻｰｾﾝ
bsd-fi と bsd-fi.mp だけの配布を検討してくだせぇ
bsd-fi と bsd-fi.mp だけの配布を検討してくだせぇ
2019/12/10(火) 12:07:56.17
OpenBSD patches authentication bypass, privilege escalation vulnerabilities
https://www.zdnet.com/article/openbsd-patches-severe-authentication-bypass-privilege-escalation-vulnerabilities/
The vulnerabilities have been assigned as CVE-2019-19522, CVE-2019-19521, CVE-2019-19520, and CVE-2019-19519.
https://www.zdnet.com/article/openbsd-patches-severe-authentication-bypass-privilege-escalation-vulnerabilities/
The vulnerabilities have been assigned as CVE-2019-19522, CVE-2019-19521, CVE-2019-19520, and CVE-2019-19519.
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で出されたみたいだね。
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で出されたみたいだね。
2019/12/10(火) 19:04:06.30
セキュリティホールはたった5つだけ
2019/12/10(火) 19:05:21.16
書き換えておこう
Only two five holes in the default install, in a heck of a long time!
Only two five holes in the default install, in a heck of a long time!
2019/12/10(火) 19:05:43.66
こうだw
Only five remote holes in the default install, in a heck of a long time!
Only five remote holes in the default install, in a heck of a long time!
2019/12/10(火) 20:23:53.64
No secrity hole in every newest version of OpenBSD, in a heck of a long time!
2019/12/13(金) 13:20:19.28
013 来てるよ
369名無しさん＠お腹いっぱい。
2019/12/14(土) 20:11:45.53 OpenBSDの起動後、ログイン画面まで進まなくなりました
どうすればログイン画面まで進む状態に戻せますか
（状況）
1. Full Disk Encryption（FDE）されたディスクにOpenBSDをインストールして使っています
2. さきほどOpenBSDを起動してログイン画面まで進んだところで強制終了させました
3. もう一度電源を入れると、FDEのパスワードを入力する画面までは進みました
4. FDEのパスワードを入力しReturnキーを押すと、起動直後の画面に戻ってしまいます
どうすればログイン画面まで進む状態に戻せますか
（状況）
1. Full Disk Encryption（FDE）されたディスクにOpenBSDをインストールして使っています
2. さきほどOpenBSDを起動してログイン画面まで進んだところで強制終了させました
3. もう一度電源を入れると、FDEのパスワードを入力する画面までは進みました
4. FDEのパスワードを入力しReturnキーを押すと、起動直後の画面に戻ってしまいます
2019/12/14(土) 20:21:33.60
>>369
> どうすればログイン画面まで進む状態に戻せますか
1. インストール直後にフルバックアップしておいたデータを使って復元する
2. (バックアップがなければ)新規に再インストールする
バックアップを取らなかった時点で負けと考えよう。いい勉強になったね。
> どうすればログイン画面まで進む状態に戻せますか
1. インストール直後にフルバックアップしておいたデータを使って復元する
2. (バックアップがなければ)新規に再インストールする
バックアップを取らなかった時点で負けと考えよう。いい勉強になったね。
371369
2019/12/14(土) 20:22:56.85 FDEのパスワードを入力してreturnキーを押したあと、起動直後の画面に戻るまでに次のように表示されます
boot>
booting sr0a:/bsd: （省略）
entry point at 0x1001000
boot>
booting sr0a:/bsd: （省略）
entry point at 0x1001000
372369
2019/12/14(土) 20:29:41.602019/12/14(土) 21:09:51.87
やったことないからただの案だけど、別のディスクとかusbでbootして問題のディスクをfsckするってのは？
374369
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をマウント
ありがとうございます
その方法で無事にディスクの内容が読めるようになりました
実施した作業の手順
1. SATA接続用のSSDをUSBで接続できるようにする装置を購入
2. OpenBSDが起動できるパソコンに、起動できなくなったSSD（以外、単に「SSD」と書きます）をUSBで接続
3. bioctlを使い、SSDを復号
4. SSDに対しfsckを実施
5. SSDをマウント
2019/12/15(日) 23:54:10.18
>>374
おお、よかったね。fsckは偉大。
おお、よかったね。fsckは偉大。
2019/12/16(月) 00:30:35.92
>>374
おめ
おめ
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がインストールできる
なんでですか
$ pkg_info -Q firefox
としても
firefox-esr-68.2.0
firefox-esr-68.3.0
の2つしか表示されない
でも
$ pkg_add firefox
とするとfirefox-69.0.2p0がインストールできる
なんでですか
2019/12/21(土) 06:24:47.71
015
016
セキュリティパッチ来てるﾖｰ
016
セキュリティパッチ来てるﾖｰ
2020/01/01(水) 07:13:57.36
初夢
intel NICのドライバが原因でシステムクラッシュ、電源切断の憂き目に遭ったw
intel NICのドライバが原因でシステムクラッシュ、電源切断の憂き目に遭ったw
2020/01/01(水) 10:22:54.76
残念、今朝のは初夢とは言わんよ、日本人なら
2020/01/01(水) 20:21:50.67
こんなところにもネトウヨが
2020/01/02(木) 16:35:49.98
ネトウヨというにはちょっと微妙だが、ラズパイのとこに来てる人と同じだったらそうだな。
383名無しさん＠お腹いっぱい。
2020/01/14(火) 11:17:25.27 >>361 河豚板のカーネルだけ欲しいってことだよね？ 何が目的？
2020/01/18(土) 12:55:33.19
新年初パッチ
2020/01/18(土) 13:17:02.75
あけおめパッチか
2020/01/18(土) 15:02:56.05
AMDer のおまえらには関係ないですw
レスを投稿する
ニュース
- 【ライバー刺殺】被害者はフィアンセとタワマン暮らし、旅行「なら1万円でもいいから返して！」高野容疑者（42）は事件5日前にもDMを ★6 [ぐれ★]
- 【ライバー刺殺】被害者はフィアンセとタワマン暮らし、旅行「なら1万円でもいいから返して！」高野容疑者（42）は事件5日前にもDMを ★7 [ぐれ★]
- 「野放し状態」のSNS誹謗中傷、本当に減らせる？ 「即削除・凍結」を可能にする法律、いよいよ始まるけど [蚤の市★]
- 【大阪関西万博】大地震発生なら夢洲は孤立の恐れ 来場者の安全どう守る？ [七波羅探題★]
- 女性ライバー刺殺｢時間かかると思うけど絶対返すから100万かりたい｣｢もう頼まないから5万だけおねがいしていい？｣金銭トラブル詳細★6 [Ailuropoda melanoleuca★]
- 「日本財政破綻は真っ赤な嘘」勢い増す怒りの財務省解体デモ 大学2年女性(20)「汗水たらして働いて搾取に憤りを感じた」★3 [お断り★]
- 【悲報】アリエクSHEINで仕入れた中国ペラペラ服980/円を1万で売りつける店がパルコに現る [732289945]
- 【悲報】フランス、「USAID」確定😡中銀総裁「トランプ大統領の関税政策は、まず何よりアメリカ経済にとって悲劇😠」 [519511584]
- 最上あいこと佐藤愛里さん(22)は滅多刺しにされて殺されんだぞ？それでも罪が消えず日本中から叩かれるって彼女はそこまでの悪人なのか？ [689851879]
- 最上あいさんの殺害現場にロックアイスが供えられる。なんでロックアイス？⎛´･ω･`⎞ [931948549]
- 最上あいを名乗る佐藤愛里さん、18歳で出産したシングルマザーで経済的には困窮していた。タワマンも婚約者も全て妄想だったのか？ [389326466]
- 【悲報】最上あいちゃんは殺されて当然のゴミクズという風潮、広まり始める