by
Anonymous Coward
on 2019年07月17日 21時51分
(#3653278)
> UUID generation: UUIDs are supposed to be universally unique but are not cryptographic key material. ソースのコメントに書いてあることから察すると、UUIDが被るのが起動しない原因っぽい。 つまり、生成された乱数が被らないことを期待してRDREAND叩いていたsystemdの設計が糞ってこと。
買わない理由ができた (スコア:2, おもしろおかしい)
Ryzen2にも問題があるらしいので、BIOSのアップデートで改善されるとはいえ、なんか気に入らないので、Ryzen3を待つぜ。
Haswell延命の理由ができた。
Re: (スコア:0)
2019-07-07 に発売されたのは Zen2 アーキテクチャに移行した 3世代目の Ryzen なんですけどね
なので ずーっと待ってもおそらく Ryzen3 ってのは出ないと思いますよw
Re: (スコア:0)
何言っているんですか!
Ryzen3 どころかもう Ryzen9 まで出ていますよ!
# Zen2 世代の G 付きが欲しかった……
Re:買わない理由ができた (スコア:1)
何言っているんですか!
Ryzen3 どころかもう Ryzen9 まで出ていますよ!
知っているのかっ!Ryzen3
乱数なら-1が連続してもいいのでは (スコア:0)
乱数に何を期待しているのか。
Re:乱数なら-1が連続してもいいのでは (スコア:3)
さすがに、ずっと-1だと作られるハッシュがずっとコリジョンしちゃう。
Re: (スコア:0)
ハッシュのシード値を何だと思っているのか。
Re:乱数なら-1が連続してもいいのでは (スコア:1)
普通は unsigned ですよね???
Re: (スコア:0)
少なくとも-1という特定の値が連続することは期待してないだろう。
それでよければ最初から乱数ではなく-1の固定値を使えばいいだけの話だしね。
Re:乱数なら-1が連続してもいいのでは (スコア:3, 興味深い)
-1しか出目が無いのは乱数とは言えないけど出目が連続するのなんか当たり前(むしろ絶対に連続して同じ値が出ないと規定するほうが乱数としては悪い)だし
そもそもランダム性が無いとブートできない理由がわからない
あちこちに本の虫を読めとオウムみたいな書き込みがあったから読んでみたけど結局理由は書いてないし
Re:乱数なら-1が連続してもいいのでは (スコア:1)
ああ、確かに「(2-64の確率で)出目が連続したときにブートしない不具合」とも言えるか
Re:乱数なら-1が連続してもいいのでは (スコア:1)
同じ値が来たらブートできない脆弱性があるということですか?
つまり、RDRAND命令を使わない場合でも天文学的確率でブート不能な場合があるということで…
Re:乱数なら-1が連続してもいいのでは (スコア:2)
同じハッシュ値を持ちたくないって仕様だから、前と同じシード値が来たら、
普通は異なる値が来るまでリトライするよね。
乱数であれば、そのうち、別の値になることが期待できるだろうし…
でも、延々リトライさせてストールさせるわけにはいかないから、
ある程度繰り返しても変化がなければそこで、処理をあきらめる必要がある。
で、今回の件はかならず -1 を返すので必ずリトライオーバでブートに失敗する
ってのは、systemd が要求している仕様からでも導けるし、
通常の乱数の中で同じ値がたまたま数回連続しても、ほぼ大丈夫な実装だろう
ことは想像できると思うのだけど
Re: (スコア:0)
なんか嫌なことでもあったの?
Re: (スコア:0)
職質でもされたんだろう
Re: (スコア:0)
ハッシュのシード値にしてるだけなら-1でも別に問題ないので、ブートしない理由になってなくない?(と調べずにコメントする)
Re: (スコア:0)
> 今時ハッシュテーブルを毎回同じで初期化するとかバカなのレベルだし
いやいや、「毎回同じで初期化する」処理でなんでブートできないのって話題で、
これはこれで脆弱性なのでは?という話です。
Re: (スコア:0)
別に環境的にそうであるならそのまま使っても良いじゃん。
安全性高くできるならその様に、出来ないのならやっぱりその様に使えば良いだけじゃ。
んでもって、「AMDだと安全性に疑問があるから直してね」って言えば良いだけに思えるが。
Re: (スコア:0)
-1でブートするように書き換えてビルドしろと
Re: (スコア:0)
ハッシュテーブルのシード値が毎回変わらないからと言ってブートできなくなるのは、
「Linuxは低い確率でリブートに失敗します」
ってこと
Re:乱数なら-1が連続してもいいのでは (スコア:1)
乱数って同じ値が連続する事は絶対ないのでしたっけ?
Re: (スコア:0)
純粋な乱数で-1が連続した場合正常に動作しないコードってこと?
乱数って必ず-1が連続してはならないって定義あったっけ?
Re: (スコア:0)
慣れないながらもソース読んでみたけど分からんね
・hashmap の初期 hash_key に使っている
→初期値にだけ使ってるから衝突しないし、衝突しても O(N) になるだけだし問題ない(のが普通だよね)
・root パスワード暗号化のソルトに使ってる
→暗号強度的なチェックが入っていれば引っかかりそうだけど、見つからず
・UUID で使ってる?
→コメントでは使っていると書いているけど見つからず。ただ same_entry で同じ UUID がないかのチェックをしていて、これに失敗するとコケるっぽい
UUID がぶつかるのって天文学的確率だし、私も衝突しない前提で書くこと多いけど……バグまで考慮するとそうもいかないのか
UUIDの衝突が原因で失敗したっぽい? (スコア:0)
ソースコードは読めないペーペーなので、どこで使っているかは確認してませんが、
本の虫でリンクされているコードのコメントによると、サービスにinvocationIDを採番する
(システムの起動直後ではシステム固有のID(?)が取得できないため乱数に頼るしかないらしい)のに使用しているらしいです。
で、該当のコードのログをたどると、#11810 [github.com]で、
UUIDの衝突のために、invocationIDが採番できずに処理が失敗するとあるようです。
# ブートではなくて、終了時の話だけど・・・
ryzen2も同じバグ (スコア:0)
があったやべーな
Systemdでは暗号化などのために乱数を使用しているわけではない (スコア:0)
では、何のために使っているのでせうか
プロセスIDとか?
Re:Systemdでは暗号化などのために乱数を使用しているわけではない (スコア:2)
% hostnamectl
Static hostname: strawberry
Icon name: computer-desktop
Chassis: desktop
Machine ID: 31adb60a1a4a61feb40a9bf15c9f824f
Boot ID: 80c6bca063aa41588c5e264f20c39140
Operating System: ]8;;https://www.gentoo.org/Gentoo/Linux]8;;
Kernel: Linux 5.1.17-gentoo
Architecture: x86-64
Re:Systemdでは暗号化などのために乱数を使用しているわけではない (スコア:1)
シードとか、UUIDとか、そこまでの精度が要るものなのかね…/dev/randomが十分でないっていうのなら、なんでも取り込むsystemdの流儀に従って、systemd-randomとかを作って自前で乱数供給したらいいんじゃない?
Re: (スコア:0)
本の虫に書いてあんじゃん
そのままGithubの方も見に行けばわかるよ
Re: (スコア:0)
ははは皆そういう疑問を持つのは自然なのだから
ちょこっと伝文に書いてくれればいいのにね
みんなリンク先なんか見やしねーのは伝統
Re: (スコア:0)
本の虫よくわかんないんだよね
何て書いてあるの?
てっきり暗号化の為かと思っていたけど、 (スコア:0)
最後の一行でひっくり返された。
んじゃブート時の何に乱数が必要だったんだろう?
それもセキュラでなくても問題ないとか。
Re: (スコア:0)
本の虫の人は、とても頭が良いみたいで、俺らと違う次元にいるからなあ。
全く雑味の無い、完全に正しい事実だけを正確に文に起こしていくから
多分(理解できれば)誤解のしようのない完璧な文章なんだろうけど
感情的で感覚的に生きている俺ら一般人には、そもそも理解が難しいという。。。
Re: (スコア:0)
へ?本の虫が?雑味ない?
あんな味わい深くて、主観まみれのブログが?(もちろんフェイクサイトって意味じゃないよ)
「俺ら一般人」とやらには、完全で完璧に見えるものなの??
うーん、とりあえず、#3653086とは違う次元に属しているということはなんとなく理解できた。
Re: (スコア:0)
これって要は「使用はは非推奨なんだけど使いたいことも有るんだよ。だから使える様に実装してね」って話だよね。
記事的にそこは表に出さないとマズイ所なんじゃないかな。
何故か周辺の話ばかりで直接原因の所が逆にリンク先に隠されて居る。
その結果、同時多発的に疑問を持つ人間が出ちゃって居ると。
Re: (スコア:0)
ブート失敗する理由は見当たらないんだけど引用してくれる?
Re:てっきり暗号化の為かと思っていたけど、 (スコア:1)
> UUID generation: UUIDs are supposed to be universally unique but are not cryptographic key material.
ソースのコメントに書いてあることから察すると、UUIDが被るのが起動しない原因っぽい。
つまり、生成された乱数が被らないことを期待してRDREAND叩いていたsystemdの設計が糞ってこと。
Re: (スコア:0, すばらしい洞察)
systemdのソースなんて読みたくないな
Re: (スコア:0)
本の虫に書いてあるって言ったくせに無責任な奴だな
Re: (スコア:0)
書いてあるよ?
> もう一つの問題は、なぜsystemdはRDRANDを直接使っているのかということだ。Linuxカーネルの提供する/dev/urandomではなぜだめなのか。
> その理由は他ならぬsystemdのソースコードにコメントとして記載されている。
> https://github.com/systemd/systemd/blob/f90bcf8679e8708788290519dc0937... [github.com]
だから、嫁
エントリーポイントから追っかけて嫁とは言ってねぇ
どこを読めばいいのかもわかるんだから嫁
Re: (スコア:0)
結局,誰も理解できてなくて草
スレ崩壊 (スコア:0)
なんだかな〜
Re: (スコア:0)
なんか議論を妨害してるのがいるね。
ソースを読まないとコメントしてはいけない、
という使用許諾なんか無いんだから。
安定のSystemd (スコア:0)
単純に設計が雑なだけじゃん・・・
Re: (スコア:0)
今回のようなことが起こらないように
UEFIもsystemdに組み込むべきだな!
Re: (スコア:0)
違う、対応しているかどうかのチェック処理が走って対応しているってフラグを返すのに取得すると-1がかえんの。
死んでたらそもそも違う動作する。
死んでるならまだマシなのに中途半端に生きているからダメ案件
Re:安定のSystemd (スコア:1)
#まぁ LFSR なので Intel の実装でも真の乱数ではもともとないし、正直 AMD の CPU がちゃんとした値を返さないって昔の TSC のほうが仕様的に変だという意味で酷い気がするけど。
Re:安定のSystemd (スコア:1)
#何ヶ月に一回かインターミッテントに化けるようなバグのデバッグをやるはめになったらたぶん身にしみると思うけど。
Re:安定のSystemd (スコア:2)
ついに Devean さんの出番がきましたか
調べてみたら、systemd がデフォルトでないディストリも結構ありますね
最近人気上昇中の MX Linux も sysvinit みたいですね
A list of non-systemd distributions (revisited)
https://sysdfree.wordpress.com/2019/03/09/135/ [wordpress.com]
Re:案の定のAMD (スコア:1)