¿Por qué mi sistema * no parcheado parece * no ser vulnerable a Specter?

Dado que los artículos de investigación correspondientes ofrecen descripciones públicas bastante explícitas, supongo que publicar mi código a continuación no se considera como Fomentar o respaldar las hazañas. Sin embargo, soy consciente de que algunos respondedores pueden preferir permanecer algo vagos ...

Me confundieron varias pruebas si mis sistemas no están protegidos contra las vulnerabilidades de Specter (y Meltdown) después de parchear, ya que el parche puede: A veces parecían estar en desacuerdo o no estaba claro si una pieza adicional de software todavía se necesitaba otra. parche. Por lo tanto, tenía la intención de realizar mis propias pruebas mediante la explotación de las vulnerabilidades, en contraste con la mayoría de las herramientas de prueba mencionadas, que en lugar de leer varios tipos de información de estado y CPU.

Considere el siguiente fragmento de código ...

#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];
  }
}

El if se evalúa como true 99 veces seguidas (lo que provoca que se obtenga un line determinado por other para cachear y leer) y luego una vez para false . Por lo tanto, asumo que en la última ejecución, la predicción de rama se engaña en especulativamente ejecutando (pero luego abandonando) la tarea. En particular, un line determinado por el contenido de secret se recupera en la memoria caché, incluso aunque el contenido de secret nunca se lea "realmente" (es decir, de manera no especulativa).

Después de eso, cronometro el acceso a las diversas líneas y espero un tiempo significativamente más corto para el line determinado por el contenido de secret (es decir, la lectura de A[256+'H'] debería ser más rápida que los accesos a otros A[256+c] ).

Sin embargo, siempre mido > 1000 ciclos para todos los accesos de prueba, mientras que esperaría < 100 ciclos para acceder a una línea ya en caché. (Podría verificar el tiempo más corto cambiando la condición if y haciendo el acceso "real" en lugar de solo especulativo).

Para mí, ¡esto parece que la vulnerabilidad de Spectre no existe en absoluto, es decir, ¡¡la captura de memoria caché especulativa no ocurre ?! Pero intenté específicamente esto en un sistema que no ha actualizado kernel / compiler / BIOS / firmware / microcode. Al menos eso es lo que parece spectre-meltdown-checker.sh para confirmar:

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

Entonces, irónicamente, la última línea de esta salida parece aplicarse a mi prueba local: no expone la vulnerabilidad a pesar de que el sistema es vulnerable. P: ¿Por qué mi prueba falla de esta manera? ¿Qué hay de malo en mi argumento anterior "probar" que debería exponer la vulnerabilidad?

Comentario: , por supuesto, compilé mi código sin optimización, así que tenga la seguridad de que el ensamblador generado coincide con la estructura de la fuente (verifiqué esto con objdump ). Además, lo anterior es solo la versión más básica del código que probé; para "estimular" la especulación, hice que el if dependiera de un cálculo relativamente largo y el then -body consiste en una sola instrucción (desmontada como

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