Spectre и Meltdown

Блок TLB не имеет программного (микропрограммного) управления, как обычный кеш. Из него невозможно удалить запись

Блок TLB не имеет программного (микропрограммного) управления, как обычный кеш. Из него невозможно удалить запись, либо принудительно внести/модифицировать какую-либо запись.

Все патчи уязвимостей Spectre и Meltdown предложенные производителями ПО это и делают, перезагружая в обработчике исключения GP регистр CR3.

Первым делом нужно в программе создать буфер размером 2 мегабайта, причем в этот буфер нельзя писать/читать до проведения атаки и он должен располагаться на границе 4К блока. Этот размер принципиален, в буфере должны разместиться ровно 256 страниц по 4К (специфика пейджинговой адресации).

al читается значение их ядра ОС, байт!

Все патчи уязвимостей Spectre и Meltdown предложенные производителями ПО это и делают, перезагружая в обработчике исключения GP регистр CR3.

Проблема в блоке TLB, который используется в пейджинговой адресации оперативной памяти. Он является ассоциативным буфером хранящим пары значений виртуальный-физический адрес используемой приложением в оперативной памяти.
Это не Кеш данных….

до проведения атаки и он должен располагаться на границе 4К блока. Этот размер принципиален, в буфере должны разместиться ровно 256 страниц по 4К (специфика пейджинговой адресации).

if (untrusted_offset_from_user < arr1->length) {
     unsigned char value = arr1->data[untrusted_offset_from_user];
     unsigned long index2 =((value&1)*0x100)+0x200;
     if (index2 < arr2->length) {
         unsigned char value2 = arr2->data[index2];
     }
 }

Все патчи уязвимостей Spectre и Meltdown предложенные производителями ПО это и делают, перезагружая в обработчике исключения GP регистр CR3.

Это уже дело техники, «прозвоним» блок TLB. Для этого нужно по одному разу прочитать все его страницы по 4К, их ровно 256

Не ищите этого названия в Интернете, метод был известен в очень узких кругах совершенно не публичных специалистов.

Извините, но в статье написана примерно неправда, а гонор совершенно не оправдан.
В этом несложно убедиться https://newsroom.intel.com/wp-content/uploads/sites/11/2018/01/Intel-Analysis-of-Speculative-Execution-Side-Channels.pdf

--

Проблема не в TLB, а в спекулятивном выполнении с неявным кешированием.

На схеме TLB нарисован не совсем адекватно, точнее очень упрощенно-условно.
TLB также управляет кешированием (noncached, write combine) и конечно работает как при чтении, так и при записи. Поэтому корректней было-бы обозначить его "прокладкой-слоем" вокруг всей подсистемы кеширования.

Тем не менее, промах в TLB дороже промаха в кеше. Проще говоря, TLB-промахи легче заметить и они мешают увидеть кеш-промахи. Что оказывает соответствующее влияние на реализацию атак. Поэтому не 1 мегабайт, а 2.

CR3 перезагружается не для сброса TLB, а для KPTI.
И не только в обработчике исключения, а при каждом переключении user-mode/kernel-mode.
И не против Spectre, а только против Meltdown.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5aa90a84589282b87666f92b6c3c917c8080a9bf

--

В продолжение темы:
Есть unstable microcode от Intel, можно пробовать лечиться и/или баловаться.

На всякий обращу внимание:
1) Это НЕ официальный и НЕ финальный microcode, выпущенный в конце ноября и начале декабря (Intel в курсе проблем с начала лета).
2) LFENCE в Changelog упоминается в контексте "Spectre variant #2". Тогда как в публикации Intel (по ссылке выше) в контексте "Bounds Check Bypass Mitigation", т.е. "Spectre variant #1".

Отсюда напрашивается предположения:

• либо в Changelog очепятка (2 вместо 1) и на разных моделях было отличие в поведении LFENCE, которое исправлено в этом микрокоде;
• либо поведение LFENCE всё-таки имеет какой-то эффект на "Spectre variant #2", но в публикации Intel это упустили в спешке.

Changelog:
2018-01-04 — Henrique de Moraes Holschuh hmh@debian.org
intel-microcode (3.20171215.1) unstable; urgency=high

• Add supplementary-ucode-CVE-2017-5715.d/: (closes: #886367)
  New upstream microcodes to partially address CVE-2017-5715
• Updated Microcodes:
  sig 0x000306c3, pf_mask 0x32, 2017-11-20, rev 0x0023, size 23552
  sig 0x000306d4, pf_mask 0xc0, 2017-11-17, rev 0x0028, size 18432
  sig 0x000306f2, pf_mask 0x6f, 2017-11-17, rev 0x003b, size 33792
  sig 0x00040651, pf_mask 0x72, 2017-11-20, rev 0x0021, size 22528
  sig 0x000406e3, pf_mask 0xc0, 2017-11-16, rev 0x00c2, size 99328
  sig 0x000406f1, pf_mask 0xef, 2017-11-18, rev 0xb000025, size 27648
  sig 0x00050654, pf_mask 0xb7, 2017-11-21, rev 0x200003a, size 27648
  sig 0x000506c9, pf_mask 0x03, 2017-11-22, rev 0x002e, size 16384
  sig 0x000806e9, pf_mask 0xc0, 2017-12-03, rev 0x007c, size 98304
  sig 0x000906e9, pf_mask 0x2a, 2017-12-03, rev 0x007c, size 98304
• Implements IBRS and IBPB support via new MSR (Spectre variant 2
  mitigation, indirect branches). Support is exposed through cpuid(7).EDX.
• LFENCE terminates all previous instructions (Spectre variant 2
  mitigation, conditional branches).

https://debian.pkgs.org/sid/debian-nonfree-amd64/intel-microcode_3.20171215.1_amd64.deb.html

; rcx = kernel address
; rbx = probe array
retry:
mov al, byte [rcx]
shl rax, 0xc
jz retry
mov rbx, qword [rbx + rax]