web-dev-qa-db-ja.com

パッチを適用していないシステムがSpectreに対して脆弱ではないように見えるのはなぜですか？

対応する 研究論文 は非常に明確な説明を公に提供しているため、以下の私のコードの公開は、エクスプロイトを奨励または承認するものとは見なされません。それにもかかわらず、一部の回答者はやや曖昧なままでいることを好むかもしれないことを知っています...

システムがSpectre（およびMeltdown）の脆弱性から保護されているかどうかにかかわらず、パッチが可能なようにパッチを適用した後、さまざまなテストで混乱しました。したがって、私は実際に脆弱性を悪用して独自のテストを行うつもりでした-いくつかの種類のCPUとステータス情報を読み取る前述のテストツールのほとんどとは対照的です。

次のコードスニペットを検討してください...

#define CACHELINESIZE   4096
typedef char line[CACHELINESIZE];
line A[512];

char secret = 'H';
char any = 'X';

#define REP     100
char* pcheck[REP];
line* pwrite[REP];
for (int i=0; i<REP; i++) {
  pcheck[i] = &any; 
  pwrite[i] = A; 
}
pcheck[REP-1] = &secret;
pwrite[REP-1] = A+256;
char dummy;
for (int i=0; i<REP; i++) {
  if (i != (REP-1)) {
    dummy = pwrite[i][*pcheck[i]][0];
  }
}

ifは、続けて99回trueに評価され（lineによって決定されたotherがキャッシュにフェッチされ、そこから読み取られる）、次にfalseに1回評価されます。したがって、私は最後の実行で、分岐予測が投機的に割り当てに実行された（しかし後で放棄された）にだまされていると想定します。特に、lineの内容が "実際に"（つまり、非投機的に）読み取られることはありませんが、secretの内容によって決定されるsecretはキャッシュにフェッチされます。

その後、さまざまな行へのアクセスの時間を計り、lineの内容によって決定されるsecretの時間が大幅に短くなることを期待します（つまり、A[256+'H']からの読み取りは、他のA[256+c]へのアクセスよりも高速です）。

ただし、私は一貫してすべてのテストアクセスに対して1000サイクルを測定しますが、すでにキャッシュされたラインへのアクセスには100サイクル未満を期待します。 （if条件を変更して、アクセスを投機的なものだけでなく「実際の」ものにすることで、短い時間を確認できました）。

私には、これはまるでSpectreの脆弱性がまったく存在しないかのように見えます。つまり、投機的なキャッシュフェッチは発生しません！？しかし、私は特にカーネル/コンパイラ/ BIOS /ファームウェア/マイクロコードを更新していないしないシステムでこれを試しました。少なくともそれが spectre-meltdown-checker.sh で確認できるようです：

Spectre and Meltdown mitigation detection tool v0.29

Checking for vulnerabilities against running kernel Linux 4.4.0-104-generic #127-Ubuntu SMP Mon Dec 11 12:16:42 UTC 2017 x86_64
CPU is Intel(R) Celeron(R) CPU G530 @ 2.40GHz

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Checking count of LFENCE opcodes in kernel:  NO 
> STATUS:  VULNERABLE  (only 33 opcodes found, should be >= 70, heuristic to be improved when official patches become available)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
*   Hardware (CPU microcode) support for mitigation:  NO 
*   Kernel support for IBRS:  NO 
*   IBRS enabled for Kernel space:  NO 
*   IBRS enabled for User space:  NO 
* Mitigation 2
*   Kernel compiled with retpoline option:  NO 
*   Kernel compiled with a retpoline-aware compiler:  NO 
> STATUS:  VULNERABLE  (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI):  NO 
* PTI enabled and active:  NO 
> STATUS:  VULNERABLE  (PTI is needed to mitigate the vulnerability)

A false sense of security is worse than no security at all, see --disclaimer

つまり、皮肉なことに、この出力の最後の行は私の自作のテストに当てはまるようです。システムが脆弱であるにもかかわらず、脆弱性を公開できません。 Q：しかし、なぜ私のテストはこのように失敗するのですか？脆弱性を公開する必要があることを「証明」することに関する私の主張の何が問題になっていますか？

備考：もちろん、コードを最適化せずにコンパイルしたので、生成されたアセンブラがソースの構造と一致することを確認してください（これをobjdumpで確認しました） ）。また、上記は私が試したコードの最も基本的なバージョンにすぎません。憶測を「奨励する」ために、ifを比較的長い計算に依存させ、then- bodyを単一の命令で構成しました（

   imul   -0x66c(%rbp),%eax
   cmp    %eax,%edx
   je     4006d7 <main+0xf5>
   movzbq (%rdi),%rdi
4006d7: ...
linuxspectreintel
6
Hagen von Eitzen

パッチを適用していないシステムがSpectre（およびMeltdown）に対して脆弱ではないように見える理由は、プロセッサが脆弱性の影響を受けないためです。お使いのプロセッサーIntel（R）Celeron（R）CPU G530は、Intel [1]からリリースされた該当製品のリストに含まれていません。 Spectre/Meltdown [2] Webサイトでは、「アウトオブオーダー実行を実装するすべてのIntelプロセッサーが影響を受ける可能性があります。これは、1995年以降実質的にすべてのプロセッサーです（Intel ItaniumおよびIntel Atomを除く） 2013年より前）」[2]。CeleronG530は、順不同の実行を実装しないか、エクスプロイトまたは脆弱性の影響を受けません。2番目のケースに関しては、脆弱である可能性がありますが、エクスプロイトによって悪用されることはありません。論文が説明する（正確な）方法で脆弱ではありません。

インテルによると

[1] https://security-center.intel.com/advisory.aspx?intelid=intel-sa-00088&languageid=en-fr
[2] https://meltdownattack.com/

1
sven.to