なおZenには影響なし
Some AMD Processors Have a Hardware RNG Bug, Losing Randomness After Suspend Resume | TechPowerUp
https://www.techpowerup.com/255294/some-amd-processors-have-a-hardware-rng-bug-losing-randomness-after-suspend-resume
なおZenには影響なし
Some AMD Processors Have a Hardware RNG Bug, Losing Randomness After Suspend Resume | TechPowerUp
https://www.techpowerup.com/255294/some-amd-processors-have-a-hardware-rng-bug-losing-randomness-after-suspend-resume
やっぱceleron最強
最近のCPUには乱数生成器まであるんだな
すげえよ
現在時刻をseedにするのが普通だったのに
すげえよ
現在時刻をseedにするのが普通だったのに
>>3
20年くらい前にサイリックスが真のランダムジェネレータを乗っけたから
20年くらい前にサイリックスが真のランダムジェネレータを乗っけたから
人類って乱数作れるの？
CPUの乱数生成器ってどんな時に利用されてるの？
AMDvs月刊脆弱性インテル ファイッ！
2017年
06月01日 Googleが関係者へ「Spectre」情報を報告
07月28日 Googleが関係者へ「Meltdown」情報を報告
2018年
01月01日 Intel CPUのセキュリティ上のバグの存在を指摘する記事が公開される
01月02日 「The Register」が、IntelのCPUに欠陥があると発表
01月03日 「Google Project Zero」が脆弱性の詳細情報を公開
01月03日 やっとIntelがCPUバグの存在を正式に認める
01月12日 Intelが「Microcodeに不具合が確認された」と一部の顧客へ忠告していると報道
01月17日 Intelが複数のCPUで同問題が確認されていることを報告
01月22日 Intelが不具合の調査が終わるまでアップデートを見送るよう発表
02月05日 「Meltdown」「Spectre」を狙うマルウェアサンプルが大量に発見される
03月28日 Spectre系の脆弱性「BranchScope」、Intel製CPUで実証される
04月05日 Intelが旧型CPUの「Spectre」対策中止を発表
05月07日 IntelのCPUに新たな8つの脆弱性が発見、うち4つは高い危険性
05月22日 「Meltdown」「Spectre」関連の脆弱性が2件見つかる
06月15日 Intelプロセッサに新たな脆弱性、投機的実行機能に関連
06月27日 IntelのCPUに新たな脆弱性「TLBleed」が見つかる
07月12日 「Spectre」関連の新たな脆弱性が見つかる。Intel、ARMに影響
07月24日 脆弱性「SpectreRSB」が見つかる
07月27日 Spectreより危険度の高い脆弱性「NetSpectre」が見つかる
08月14日 脆弱性「Foreshadow」（L1TF）が見つかる
08月23日 Intel社が脆弱性対策で低下するマイクロコードアップデート前後のベンチ比較を禁止
08月23日 批判され、Intel社が↑の「ベンチ比較を禁止」を撤回
08月31日 「Intelの脆弱性情報の開示が遅すぎた」ことでLinux開発者が大変な目に遭っていたことが発覚
09月11日 情報漏洩や権限昇格、任意のコード実行などにつながる恐れの脆弱性が複数見つかる
10月10日 Intel製グラフィックドライバーやファームウェアに脆弱性、最大深刻度は“HIGH”
11月05日 Hyper-Threading搭載のIntel CPUに新たな脆弱性、9900K死亡
11月15日 「Spectre」「Meltdown」関連でIntel新たに7件の脆弱性
2019年
01月10日 Intel製品に複数の脆弱性、修正版が一斉公開 〜最大深刻度は“HIGH”
02月13日 Intel CPUのセキュリティ機構「SGX」にマルウェアを隠すことでセキュリティソフトで検出できない危険性
03月15日 Intel CPUに新たな脆弱性『Spoiler』。AMD CPUは影響なし
03月31日 Intelのチップセットにも全ての情報が取得できる脆弱性を発見
04月11日 Intel製のハードウェア、ファームウェア、ソフトなどに複数の脆弱性
2017年
06月01日 Googleが関係者へ「Spectre」情報を報告
07月28日 Googleが関係者へ「Meltdown」情報を報告
2018年
01月01日 Intel CPUのセキュリティ上のバグの存在を指摘する記事が公開される
01月02日 「The Register」が、IntelのCPUに欠陥があると発表
01月03日 「Google Project Zero」が脆弱性の詳細情報を公開
01月03日 やっとIntelがCPUバグの存在を正式に認める
01月12日 Intelが「Microcodeに不具合が確認された」と一部の顧客へ忠告していると報道
01月17日 Intelが複数のCPUで同問題が確認されていることを報告
01月22日 Intelが不具合の調査が終わるまでアップデートを見送るよう発表
02月05日 「Meltdown」「Spectre」を狙うマルウェアサンプルが大量に発見される
03月28日 Spectre系の脆弱性「BranchScope」、Intel製CPUで実証される
04月05日 Intelが旧型CPUの「Spectre」対策中止を発表
05月07日 IntelのCPUに新たな8つの脆弱性が発見、うち4つは高い危険性
05月22日 「Meltdown」「Spectre」関連の脆弱性が2件見つかる
06月15日 Intelプロセッサに新たな脆弱性、投機的実行機能に関連
06月27日 IntelのCPUに新たな脆弱性「TLBleed」が見つかる
07月12日 「Spectre」関連の新たな脆弱性が見つかる。Intel、ARMに影響
07月24日 脆弱性「SpectreRSB」が見つかる
07月27日 Spectreより危険度の高い脆弱性「NetSpectre」が見つかる
08月14日 脆弱性「Foreshadow」（L1TF）が見つかる
08月23日 Intel社が脆弱性対策で低下するマイクロコードアップデート前後のベンチ比較を禁止
08月23日 批判され、Intel社が↑の「ベンチ比較を禁止」を撤回
08月31日 「Intelの脆弱性情報の開示が遅すぎた」ことでLinux開発者が大変な目に遭っていたことが発覚
09月11日 情報漏洩や権限昇格、任意のコード実行などにつながる恐れの脆弱性が複数見つかる
10月10日 Intel製グラフィックドライバーやファームウェアに脆弱性、最大深刻度は“HIGH”
11月05日 Hyper-Threading搭載のIntel CPUに新たな脆弱性、9900K死亡
11月15日 「Spectre」「Meltdown」関連でIntel新たに7件の脆弱性
2019年
01月10日 Intel製品に複数の脆弱性、修正版が一斉公開 〜最大深刻度は“HIGH”
02月13日 Intel CPUのセキュリティ機構「SGX」にマルウェアを隠すことでセキュリティソフトで検出できない危険性
03月15日 Intel CPUに新たな脆弱性『Spoiler』。AMD CPUは影響なし
03月31日 Intelのチップセットにも全ての情報が取得できる脆弱性を発見
04月11日 Intel製のハードウェア、ファームウェア、ソフトなどに複数の脆弱性
サガ２みたいな感じ？
俺のA10無償交換はよ
これ利用して乱数調整でレアアイテム掘り当てる事できんの？
まじかよPCゲーのRTAが捗るな
CPUにバグなんて定期
もしかして例の壁ぬけ案件って
＞ダイオードの生成するノイズや熱雑音、放射性物質の崩壊による放射線をセンサで検出する等、ランダムな物理現象を用い、その信号を元に乱数を生成する
よくわからんがなんかスゴイ
よくわからんがなんかスゴイ
>>3
ほんとこれ
そんなん付いてたん！？って感じ
ほんとこれ
そんなん付いてたん！？って感じ
Zenには影響なしかよ
Red Hat Systemd（システムおよびサービスマネージャ）の主力開発者Lennart Poetteringは、低コストのノートパソコンで人気のあるAMD A6-6310 "Beema" SoCに、RdRand乱数生成命令の実装が不完全であることを発見しました
失われたらどうなるの
最近のCPUは乱数生成までできるのかよ
どんなコードで叩けるの？
どんなコードで叩けるの？
暗号絡みで使ってるんだろうか
状況再現とかスーファミかよ！
A10やA12買った筋金入りの人ってどんだけいるんだろう
>>22
筋金入りじゃ無いけどA10付き安かったから買ったゾ
筋金入りじゃ無いけどA10付き安かったから買ったゾ
>>22
DDR3が使い回せるんだよ
ryzenはメモリ買わなきゃいけねぇ
DDR3が使い回せるんだよ
ryzenはメモリ買わなきゃいけねぇ
>>6
乱数鍵を作るとき。
Httpsのページはリクエストごとに違う鍵で暗号化するからな
毎回乱数発生機を呼んでるかは知らん
乱数鍵を作るとき。
Httpsのページはリクエストごとに違う鍵で暗号化するからな
毎回乱数発生機を呼んでるかは知らん
乱数生成器ってどういう内部構造になってるんだろ
TOTO BIGの謎が解けたか
2600Kで十分おじさん大勝利
きっちりしたランダム取りたいときはハードウェアのノイズ情報とか使うはず
>>14
こんな仕掛けなのか
ちゃんと生成されてるときなら本当の乱数やん
こんな仕掛けなのか
ちゃんと生成されてるときなら本当の乱数やん
これ、パチンコパチスロに利用できないかな。
TPM1.2関連が原因なのかな？
一昔TPM2.0モジュールを付けろ的な声がちらほらあったように思う
一昔TPM2.0モジュールを付けろ的な声がちらほらあったように思う
電源投入→シャットダウンする使い方なら問題ないのか
パチンコとスロットはZ80とかいう骨董品のCPU使わないといけないんやで
amdは糞だな
その命令が乗ったのがExcavatorからでZenには影響しないって使ってる人いるの？
AMDマニアすぎるだろ
AMDマニアすぎるだろ
ジャグ連
>>36
ただでさえマイナーかつこれで乱数とか
まず世界レベルでいないかと
ただでさえマイナーかつこれで乱数とか
まず世界レベルでいないかと
Ryzenの2600K使ってるけど大勝利ってことでいいんだよな
>>29
最近はそんな手段あるのか
オッチャンの頃は時計の1／100の位を拾って来てたりしたわ
最近はそんな手段あるのか
オッチャンの頃は時計の1／100の位を拾って来てたりしたわ
誰も使ってない昔のAMDかよ
>>24
DDR3使い回す目的ならKabyLakeでよかったから・・・
DDR3使い回す目的ならKabyLakeでよかったから・・・
状況再現で暗号化解けるやつか
zen2まだかね
俺のmobilesempronはセーフ？
ハードウェアベースの乱数生成を使わなければいいじゃん
でずっと放置されてたのかよ
でずっと放置されてたのかよ
まあハードウェアのrdrand的なやつはそのままじゃ使わんだろ
つまりどうゆうこと？
なんか不都合あるの？
なんか不都合あるの？
エントロピーテーブルの一部にぶち込むくらいで単体じゃ使わん
AMD使ってるとスリープから復帰しない
>>49
熱心なAMD教徒以外は買ったことのないCPUだぞ
熱心なAMD教徒以外は買ったことのないCPUだぞ
馬鹿が”エクスカベーター以前の”ではなく”一部の”を強調して広めようとする光景が見えた
やっぱインテルファンボーイが正義
熱心な信者の俺でもA10までしか持ってないわ
HWの乱数は生成に時間かかるから殆どの場合メルセンヌツイスタみたいな擬似乱数しか使わない
>>19
cat /dev/random
cat /dev/random
やっぱりサンディだわな。
あぁ土下座の方ですか・・・
Ryzenは影響ないなら無害もどうぜんや
>>34
機械部分の制御なら十分じゃないの
機械部分の制御なら十分じゃないの
予算的にA10-7800を買ったワイ、沈黙
と思ったけどスリープしたこと一度もねえわ
と思ったけどスリープしたこと一度もねえわ
zen2出るから何も問題ないな
>>63
インテルしっかりしないとAMDがさぼるから困るわ
インテルしっかりしないとAMDがさぼるから困るわ
>>3
math.hインクルードせずにコンパイルした時に、いつも同じ乱数しか出てこなくて焦った
TurboCだとなぜか通っちゃうんだよな
math.hインクルードせずにコンパイルした時に、いつも同じ乱数しか出てこなくて焦った
TurboCだとなぜか通っちゃうんだよな
>>7
最初の半年何やってたんだ？
最初の半年何やってたんだ？
最近のランダム生成関数は暗号用(CSPRNG)と汎用(PRNG)とで特性が違うから、CPU側でランダム性が失われてもOSやライブラリ側で弾いて終わりだろう
暗号用のCSPRNGではnext bit testというチェックアルゴリズムで不合格だと次の擬似乱数を生成するので安全性はある程度確保される。
普通の/dev/random,/dev/urandomをhavegedなどで提供する場合もCPUのPRNGを直接使うケースはまずない。
GNU libcのrand()は/dev/randomから拾ってるはずだし、LinuxカーネルのPRNG/CSPRNGもCPUのRDRAND命令を信頼してないので実害はない。
が、問題はWindowsだ。Windows APIがプロプライエタリ実装で詳細が不明なため、単にRDRANDの結果を返してる可能性がある。
似たような例としては、大昔のSunOSではイーサネットのシーケンス番号が1づつカウントアップしていたのでIPスプーフィングが超簡単にできた。一度TCP handshake試行してそのシーケンス番号から数個以内に当たりの番号が確実にあるというマヌケな実装だった。
今は全てのOSで修正されているが、当時はBSD由来システム(Linux以外全部)は全てカウントアップ式になってたのでしばらく不正アクセス祭りが開催された。
当時は特定のIPアドレスからのアクセスはパスワードなしでログインできるrhostsというシステムが使われてたから、一箇所に入れれば他にも芋づる式に侵入できちゃった。
当時すでにsshは存在したが、重くて実用に耐えなかった・・・。
暗号用のCSPRNGではnext bit testというチェックアルゴリズムで不合格だと次の擬似乱数を生成するので安全性はある程度確保される。
普通の/dev/random,/dev/urandomをhavegedなどで提供する場合もCPUのPRNGを直接使うケースはまずない。
GNU libcのrand()は/dev/randomから拾ってるはずだし、LinuxカーネルのPRNG/CSPRNGもCPUのRDRAND命令を信頼してないので実害はない。
が、問題はWindowsだ。Windows APIがプロプライエタリ実装で詳細が不明なため、単にRDRANDの結果を返してる可能性がある。
似たような例としては、大昔のSunOSではイーサネットのシーケンス番号が1づつカウントアップしていたのでIPスプーフィングが超簡単にできた。一度TCP handshake試行してそのシーケンス番号から数個以内に当たりの番号が確実にあるというマヌケな実装だった。
今は全てのOSで修正されているが、当時はBSD由来システム(Linux以外全部)は全てカウントアップ式になってたのでしばらく不正アクセス祭りが開催された。
当時は特定のIPアドレスからのアクセスはパスワードなしでログインできるrhostsというシステムが使われてたから、一箇所に入れれば他にも芋づる式に侵入できちゃった。
当時すでにsshは存在したが、重くて実用に耐えなかった・・・。
ハード乱数なんて言うほど使うか？
デバグめんどいだけやん
デバグめんどいだけやん
一様でない乱数はハードで出してくれると助かる
モンテカルロはいつでも累積分布逆関数法やボックスミューラー使えるとは限らない
よく使いそうな高次の正規分布あたりでもぽんと出ると楽
モンテカルロはいつでも累積分布逆関数法やボックスミューラー使えるとは限らない
よく使いそうな高次の正規分布あたりでもぽんと出ると楽
そりゃtotoも奇跡おきるわ
乱数調整の可能性
雑音て具体的に何色じゃろ？
普通言うカラードはパワーの対数と周波数が線形だが
普通言うカラードはパワーの対数と周波数が線形だが
勘のいい人はtotoビッグバンの原因がこれだと気付く。
動作状況が関係するのは当たり前に思うけどバグなんだろうか
前におあったけどまたインテルの回し者がフカシを流布してるのか？
totoはこういうのなんかね
もとよりCPUに完全な乱数は作れないし
もとよりCPUに完全な乱数は作れないし
>>20
暗号アルゴリズムでは、出力が不規則に、偏らずに暗号化されることを重要視されるものであるけど、
それは乱数が不規則に、偏らずに作成できるかどうか、というものとは関係がないよ
暗号アルゴリズムでは、出力が不規則に、偏らずに暗号化されることを重要視されるものであるけど、
それは乱数が不規則に、偏らずに作成できるかどうか、というものとは関係がないよ
え、時刻渡しときゃいいんだろ？
>>69
Coreの開発者がいきなりインテルを退職した
Coreの開発者がいきなりインテルを退職した
>>68
RANDOMIZE (VAL(RIGHT$(TIME$,2)))
RANDOMIZE (VAL(RIGHT$(TIME$,2)))
でもなんかして0.3秒後に発射でクリティカル確定とかええやん
あら、今のハードウェアにないからZ80が重宝されてるんじゃなかったっけ
違うのか
違うのか
インテルアンチそっ閉じｗ
AMD A6-6310「Beema」で見つかったらしいね
Photon2くらいかな該当しそうなのは
Photon2くらいかな該当しそうなのは
ノイズとかマウス操作とか混ぜなよ
>>89
普通はそういう要素を取り入れられるから、乱数発生ルーチンは自前で作る
どうもデベロッパーのblogによると、今のWindowsは乱数発生ルーチンは自前なようだが、BSDやMacOSはCPUの機能を利用している模様で、ということで
「3.0以前のWindows、もしくはMacOSを、当該のAMDプロセッサで稼動させたとき」に顕在化する、という脆弱性であるというのがFAな模様
存在するのかな、そんな環境
普通はそういう要素を取り入れられるから、乱数発生ルーチンは自前で作る
どうもデベロッパーのblogによると、今のWindowsは乱数発生ルーチンは自前なようだが、BSDやMacOSはCPUの機能を利用している模様で、ということで
「3.0以前のWindows、もしくはMacOSを、当該のAMDプロセッサで稼動させたとき」に顕在化する、という脆弱性であるというのがFAな模様
存在するのかな、そんな環境
>>90
今のOSならBSDだけってこと？
BSDって見たことないわ
どこで使ってるんだ
今のOSならBSDだけってこと？
BSDって見たことないわ
どこで使ってるんだ
RYZENおじさんのワイ高みの見物
Zen2待ちおじさんおるか？
>>90
超絶レア環境
よくそんなどうでもいい仕様レベルのもの見つけたなと言ったところ
超絶レア環境
よくそんなどうでもいい仕様レベルのもの見つけたなと言ったところ
影響あるのはPhenom2あたりでハッキントシュ入れて遊んだ後にだいぶ長い間放置してた人くらい？
インテル惨敗の状況を少しでも変えたい株価操作勢ががんばってんだろうなあ
以前にも物理的に管理者権限を奪ったうえでハッキングできます、って大々的に宣伝してたっけｗ
以前にも物理的に管理者権限を奪ったうえでハッキングできます、って大々的に宣伝してたっけｗ
＞ なおzenには影響なし
はいインテルファンボーイ憤死
はいインテルファンボーイ憤死
>>83
草wwww引き継ぎとかないんかwww
草wwww引き継ぎとかないんかwww
この問題ってPentium3の時代から起きてて、当時は乱数機能のON/OFFがBIOSにあったんだよね。
だからこの機能殺しても大きな問題にならない。当時OFFにしても一般人には影響なかったんで。
だからこの機能殺しても大きな問題にならない。当時OFFにしても一般人には影響なかったんで。
>>90
Hackintoshしない限りAPUでMacOS動かす事はないだろうから実質BSD使用時とな
全体の何%なんだと
Hackintoshしない限りAPUでMacOS動かす事はないだろうから実質BSD使用時とな
全体の何%なんだと
実際は取得した乱数自体を乱数シードに使うから大して影響ない
とかになりそ
とかになりそ
シードのひとつ ね
>>95
FXのExcavatorだけだぞ
FXのExcavatorだけだぞ
FreeNasがBSDだよね
