パスワードを忘れた？ アカウント作成
Close
13959908 story
AMD

AMDのCPUにおけるRDRAND命令に不具合、Systemdが影響を受ける 110

ストーリー by hylom
そこを吸収するのがOSの仕事では 部門より

Linux向けのサービス・システム管理ソフトウェアSystemdは、いくつかのAMD製プロセッサを搭載するマシン上で適切に動作しないという。その結果、いくつかのLinuxディストリビューションでブートに失敗するなどの不具合が報告されている（Ubuntu systemd packageでのバグ報告、Phoronix、本の虫）。

2018年12月にリリースされたSystemd 240では、x86-64アーキテクチャにおいてカーネルが提供する乱数源である/dev/urandomではなくRDRAND命令を使って乱数を生成するよう変更が行われた。この変更については、システムの起動直後には/dev/urandom経由では十分なランダム性が得られないためと説明されている。

しかし、特定のAMD CPUではRDRAND命令に不具合があり、その影響でRDRAND命令を使用するよう変更されたSystemd v240以降で問題が発生することが2月に確認された。2月の時点で問題となったのはAMDのExcavatorアーキテクチャおよびそれ以前のアーキテクチャを採用するCPUで、これらのCPUではサスペンド/レジューム後にRDRAND命令がランダム値ではなく必ず「-1」（0xFFFFFFFFFFFFFFFF ）を返すようになっていたという（systemdのissuesに投稿されたコメント、TechPowerUp）。これによってsystemdが特定の状況下で乱数を得られず、問題が発生していたという。

この問題はカーネルもしくはドライバの問題だとして当初は対応されなかったのだが、その後5月になって修正コードがマージされている。ただ、現時点でリリースされている最新版であるSystemd v242ではこの修正はまだ適用されていないようだ。

そして、今度はRyzen 3000シリーズでRDRAND命令が常に不適切な値を返し、さらにそれを検出することはできないという不具合の存在が確認された。この問題は2月に確認されたものよりも影響が広く、これによってLinuxのブートに失敗する不具合が発生するとのこと。

これらの問題の影響を受けるのは、RDRAND命令を使用するよう変更されたsystemd v240以降を採用しているLinuxディストリビューション。また、この問題と原因が同じであるかは分からないが、Windows向けのゲーム「Destiny 2」でもRyzen 3000系CPUでゲームをプレイできない不具合が確認されているという（ExtremeTech）。

AMDはこれらの問題を修正するBIOSをマザーボードメーカーに提供済みで、BIOSアップデートによって対応できると説明している（Phoronix）。

また、この問題の影響を受けることが報告されているUbuntu 19.04ではすでに修正パッチを適用したパッケージがリリースされている。

なお、RDRAND命令についてはハードウェアに脆弱性がある可能性を考慮してセキュアな用途では使用すべきではないという意見もある（過去記事）。ただ、Systemdでは暗号化などのために乱数を使用しているわけではないため問題は無いと説明していた。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

AMDのCPUにおけるRDRAND命令に不具合、Systemdが影響を受ける More

  • 買わない理由ができた (スコア:2, おもしろおかしい)

    by Anonymous Coward on 2019年07月17日 17時43分 (#3653110)

    Ryzen2にも問題があるらしいので、BIOSのアップデートで改善されるとはいえ、なんか気に入らないので、Ryzen3を待つぜ。
    Haswell延命の理由ができた。

    • Re: (スコア:0)

      by Anonymous Coward

      2019-07-07 に発売されたのは Zen2 アーキテクチャに移行した 3世代目の Ryzen なんですけどね
      なので ずーっと待ってもおそらく Ryzen3 ってのは出ないと思いますよw

      • Re: (スコア:0)

        by Anonymous Coward

        何言っているんですか！
        Ryzen3 どころかもう Ryzen9 まで出ていますよ！

        # Zen2 世代の G 付きが欲しかった……

  • 乱数なら-1が連続してもいいのでは (スコア:0)

    by Anonymous Coward on 2019年07月17日 16時40分 (#3653027)

    乱数に何を期待しているのか。

    • さすがに、ずっと-1だと作られるハッシュがずっとコリジョンしちゃう。

      シェア
      親コメント

      • Re: (スコア:0)

        by Anonymous Coward

        ハッシュのシード値を何だと思っているのか。

    • 乱数なので、好きに解釈すれば良いのかも知れませんが、
      普通は unsigned ですよね???
      シェア
      親コメント

    • Re: (スコア:0)

      by Anonymous Coward

      少なくとも-1という特定の値が連続することは期待してないだろう。
      それでよければ最初から乱数ではなく-1の固定値を使えばいいだけの話だしね。

      • Re:乱数なら-1が連続してもいいのでは (スコア:3, 興味深い)

        by Anonymous Coward on 2019年07月17日 17時25分 (#3653083)

        -1しか出目が無いのは乱数とは言えないけど出目が連続するのなんか当たり前(むしろ絶対に連続して同じ値が出ないと規定するほうが乱数としては悪い)だし
        そもそもランダム性が無いとブートできない理由がわからない
        あちこちに本の虫を読めとオウムみたいな書き込みがあったから読んでみたけど結局理由は書いてないし

        シェア
        親コメント

      • Re:乱数なら-1が連続してもいいのでは (スコア:1)

        by Anonymous Coward on 2019年07月17日 17時00分 (#3653047)

        同じ値が来たらブートできない脆弱性があるということですか？
        つまり、RDRAND命令を使わない場合でも天文学的確率でブート不能な場合があるということで…

        シェア
        親コメント
        • なんで、そうなるんだろう?

          同じハッシュ値を持ちたくないって仕様だから、前と同じシード値が来たら、
          普通は異なる値が来るまでリトライするよね。
          乱数であれば、そのうち、別の値になることが期待できるだろうし…
          でも、延々リトライさせてストールさせるわけにはいかないから、
          ある程度繰り返しても変化がなければそこで、処理をあきらめる必要がある。

          で、今回の件はかならず -1 を返すので必ずリトライオーバでブートに失敗する
          ってのは、systemd が要求している仕様からでも導けるし、
          通常の乱数の中で同じ値がたまたま数回連続しても、ほぼ大丈夫な実装だろう
          ことは想像できると思うのだけど
          シェア
          親コメント

      • Re: (スコア:0)

        by Anonymous Coward

        純粋な乱数で-1が連続した場合正常に動作しないコードってこと？
        乱数って必ず-1が連続してはならないって定義あったっけ？

    • Re: (スコア:0)

      by Anonymous Coward

      慣れないながらもソース読んでみたけど分からんね
      ・hashmap の初期 hash_key に使っている
      　→初期値にだけ使ってるから衝突しないし、衝突しても O(N) になるだけだし問題ない（のが普通だよね）
      ・root パスワード暗号化のソルトに使ってる
      　→暗号強度的なチェックが入っていれば引っかかりそうだけど、見つからず
      ・UUID で使ってる？
      　→コメントでは使っていると書いているけど見つからず。ただ same_entry で同じ UUID がないかのチェックをしていて、これに失敗するとコケるっぽい

      UUID がぶつかるのって天文学的確率だし、私も衝突しない前提で書くこと多いけど……バグまで考慮するとそうもいかないのか

      • ソースコードは読めないペーペーなので、どこで使っているかは確認してませんが、
        本の虫でリンクされているコードのコメントによると、サービスにinvocationIDを採番する
        (システムの起動直後ではシステム固有のID(?)が取得できないため乱数に頼るしかないらしい)のに使用しているらしいです。

        で、該当のコードのログをたどると、#11810 [github.com]で、
        UUIDの衝突のために、invocationIDが採番できずに処理が失敗するとあるようです。

        # ブートではなくて、終了時の話だけど・・・

  • ryzen2も同じバグ (スコア:0)

    by Anonymous Coward on 2019年07月17日 16時43分 (#3653031)

    があったやべーな

  • では、何のために使っているのでせうか
    プロセスIDとか?

  • てっきり暗号化の為かと思っていたけど、 (スコア:0)

    by Anonymous Coward on 2019年07月17日 16時48分 (#3653035)

    最後の一行でひっくり返された。
    んじゃブート時の何に乱数が必要だったんだろう？
    それもセキュラでなくても問題ないとか。

  • スレ崩壊 (スコア:0)

    by Anonymous Coward on 2019年07月17日 17時18分 (#3653071)

    なんだかな〜

    • Re: (スコア:0)

      by Anonymous Coward

      なんか議論を妨害してるのがいるね。
      ソースを読まないとコメントしてはいけない、
      という使用許諾なんか無いんだから。

  • 安定のSystemd (スコア:0)

    by Anonymous Coward on 2019年07月17日 18時25分 (#3653141)

    単純に設計が雑なだけじゃん・・・

    • Re: (スコア:0)

      by Anonymous Coward

      今回のようなことが起こらないように
      UEFIもsystemdに組み込むべきだな!

    • Re: (スコア:0)

      by Anonymous Coward

      違う、対応しているかどうかのチェック処理が走って対応しているってフラグを返すのに取得すると-1がかえんの。
      死んでたらそもそも違う動作する。
      死んでるならまだマシなのに中途半端に生きているからダメ案件

      • 任意の数だけ -1 が続く確率は、真の乱数なら０にはならないので、純粋に血塗れに Systemd が悪い。そんなもの期待する方が大間違い。

        ＃まぁ LFSR なので Intel の実装でも真の乱数ではもともとないし、正直 AMD の CPU がちゃんとした値を返さないって昔の TSC のほうが仕様的に変だという意味で酷い気がするけど。

        シェア
        親コメント
typodupeerror

「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常