Нет, но виноват ВСЕГДА разработчик продукта если не доказано что пользователь делал что то не так. То есть если пользователя убил током телевизор сделанный из говна и палок то тут явно к производителю вопрос.

To complete the attack, the adversary simply needs to detect the change in the cache state to recover

чето мне кажется к cache state change атакам вообще ничего не устойчиво. состояние же кеша точно может быть функцией данных программы и мы можем и безо всякого спекулятивного выполнения вызывать «гаджеты». не очень понятно пока, что даёт спекуляция и почему на arm9 такое не прокатит

"Intel(R) Pentium(R) Dual CPU T2330" подвержен Spectre...

Таки завелось с патчами...
>>> https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9e3d4bb6#gistcomme...

... но большинство букв декодировало как "?"

много информации, только работающего демо кода пока не нашел

Вы в курсе, что коврик это отмазка, а реально была ошибка в прошивка ЭБУ, которую писал криворукий рикша?

Вот ужо DARPA сотворит «Morpheus» ©, тогда «все напасти нам будут трын-трава» :)

намеренно?

Конечно, обратите внимание

https://www.ixbt.com/news/2018/01/04/pojavilis-pervye-testy-processorov-intel...

в играх производительность увеличилась!

нет не в курсе, но проблема была на стороне производителя что суд вроде как и установил.

Увеличь значение threshold.

Да, воспроизводится, но частично
>>> https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9e3d4bb6#gistcomme...

но виноват ВСЕГДА разработчик продукта если не доказано что пользователь делал что то не так

В данном случае я не уверен. Но, если ты прав, то будет весело. Впрочем, сейчас Intel пробует другую тактику защиты - «у нас всё работает как надо, а то, что этим могут воспользоваться плохие люди - не наша проблема»: https://www.pcworld.com/article/3245508/components-processors/intel-responds-...

“The processor is in fact operating as we designed it,”

Прокатит ли это в суде - ХЗ.

Месяц уязвимостей объявляю открытым!

Microsoft, как ожидается, публично представит необходимые изменения для своей операционной системы Windows в ближайший «Вторник патчей» (Patch Tuesday): эти изменения были распространены среди бета-тестировщиков в ноябре и декабре.

https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/

Гуня, а RISC-V твой SIMD может?

... но большинство букв декодировало как "?"

Несколько раз запусти.

похоже спекуляция в проце нужна только для того, чтобы через известный side channel в виде btb и кеша проще проще можно было прочитать всю память. то есть базовая уязвимость аффектит вообще все процессоры с защитой памяти, но универсальный код сложнее написать

грубо говоря спекуляция позволяет в cache state отобразить содержимое более произвольной области памяти, так как откладывает проверку на доступ к этой памяти. но сам принципиальный ченнел - состояние кеша зависит от памяти процесса и доступно атакующему - вообще фича всех процессоров

Покрутил и трешхолд и многоразовый запуск делал - всёравно не получается получить полную расшифровку всех букв в одном выхлопе: то одни, то другие буквы рандомным порядком выводятся как "?".

anonymous_incognito, meltdown — утечка ядерного топлива, не?

Которая и происходит при расплавлении.

С мультитрана

meltdown сущ. общ. разрушение из-за расплавления (напр. ядерного реактора); взрыв ядерного реактора (Дмитрий_Р); обвал финансового рынка (Дмитрий_Р); катастрофические и неуправляемые процессы в ядерном реакторе, сопровождающиеся повышением температуры (bigmaxus); неудача (bigmaxus); полный крах (bigmaxus); провал (bigmaxus); slang term for an emotional breakdown (masha); расплавление ядерных топливных элементов реактора (Taras)

Всё верно переведено.

А вообще стоит ли это расценивать как фундаментальную ошибку архитектуры x86?

Привет из 2008 http://m.cnews.ru/news/top/kasperskij_vzlomal_protsessory_intel

мне вот интересно было бы услышать специалиста, который бы толком объяснил что происходит.

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

Патчи для 98 семёрочки уже выпустили? Дайте ссылку.

Привет из 2007. Там же:

Другие специалисты ранее уже отмечали опасность такого рода уязвимостей в процессорах Intel. В июне прошлого года (2007 ,- прим.) Тео де Раад (Theo de Raadt), основатель OpenBSD, заявлял, что эти чипы «ужасно плохие». «Некоторые из этих уязвимостей не только вызывают проблемы при разработке, но в скором времени могут быть использованы для взлома», — сказал он

meltdown — утечка ядерного топлива, не?

Из словаря LingvoUniversal (En-Ru)

  сущ. 
 1) расплавление ядерных топливных элементов реактора; разрушение реактора из-за такого расплавления; авария на АЭС 
   Three Mile Island meltdown — авария на атомной станции на островеТри-Майл, шт. Пенсильвания (произошла в 1979 г.) 
 2) катастрофа; крах; провал; банкротство 
   financial meltdown — финансовый крах; банкротство 
 3) потеря контроля над собой 
   on the point of a psychotic meltdown — на грани нервного срыва

Из словаря Americana (En-Ru)

  расплав, авария на АЭС 
  Авария на атомной станции "Тримайл-Айленд" [Three Mile Island] в 1979, 
в результате которой произошел частичный расплав урановых стержней. 
Сегодня понятие стало синонимом крупной катастрофы в атомной энергетике и 
из технического языка вошло в разряд бытовой лексики. 
Также нарицательно используется понятие "Чернобыль" [Chernobyl]

Из словаря Computers (En-Ru)

  глобальная авария 
  авария, касающаяся всей системы или компьютерной сети 
  Syn: 
  total failure

ну возможно алгоритм программы работать может так, событием предусмотрено выполнение команд А и B, но к ним добавляют произвольную команду С, которая в определенных случаях срабатывает хотя не должна была бы. А - условие задачи, В - итог, С 0 - отправить дамп памяти в общедоступную часть памяти где происходит свободно исполняемая задача Z - email to:.

ну может как то так, другого пока в голову ненафантазировалось.

MacBook Pro (15–inch, 2017) 2,8 GHz Intel Core i7. (MacOS 10.13.2 (17C88))

$ gcc –std=c99 –O0 spectre.c –o spectre
$./spectre 
Reading 40 bytes:
Reading at malicious_x = 0xfffffffffffffeb6... Unclear: 0x54=’T’ score=983 (second best: 0x00 score=887)
Reading at malicious_x = 0xfffffffffffffeb7... Success: 0x68=’h’ score=2 
Reading at malicious_x = 0xfffffffffffffeb8... Success: 0x65=’e’ score=9 (second best: 0x04 score=2)
Reading at malicious_x = 0xfffffffffffffeb9... Unclear: 0x20=’ ’ score=987 (second best: 0x00 score=883)
Reading at malicious_x = 0xfffffffffffffeba... Unclear: 0x4D=’M’ score=977 (second best: 0x00 score=858)
Reading at malicious_x = 0xfffffffffffffebb... Unclear: 0x61=’a’ score=993 (second best: 0x00 score=913)
Reading at malicious_x = 0xfffffffffffffebc... Success: 0x67=’g’ score=2 
Reading at malicious_x = 0xfffffffffffffebd... Unclear: 0x69=’i’ score=993 (second best: 0x00 score=894)
Reading at malicious_x = 0xfffffffffffffebe... Unclear: 0x63=’c’ score=980 (second best: 0x00 score=914)
......

Most modern processors, in particular with Intel microarchitecture since 2010, are affected.

А петушки лора кудактают-обновляйтесь, обновляйтесь, говно железо, кококо...

Тоже самое, покрутил 80, 100, 150, 300, 600, компиляция:

gcc -std=c99 -O0 -o spectre spectre.cpp 

В результате почти всегда ?, иногда проскакивает 1-2 буквы, но скорее статистический мусор. Процессор:

cat /proc/cpuinfo
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 42
model name	: Intel(R) Core(TM) i7-2670QM CPU @ 2.20GHz
stepping	: 7
microcode	: 0x29
cpu MHz		: 2192.825
cache size	: 6144 KB
physical id	: 0
siblings	: 8
core id		: 0
cpu cores	: 4
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm epb tpr_shadow vnmi flexpriority ept vpid xsaveopt dtherm ida arat pln pts
bugs		:
bogomips	: 4387.38
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

Уязвимости подвержены процв с 95го года, еще вопросы?

Может это запланированное пересаживание всей планеты на другую архитектуру? На ARM, на MIPS?

Сходу есть гист на тестирование meltdown? И что там, заплатка уже есть в ядре, арч обновлять?

Уязвимости подвержены процв с 95го года, еще вопросы?

Тогда, как понять вот это

Most modern processors, in particular with Intel microarchitecture since 2010, are affected.

Источник. Неверная информация?

но если это не считается уязвимостью, почему такая истерия от частного случая, когда благодаря отложенному выполнению команд нам становится это _доступное_ состояние кеша проще менять.

Было на bash.org
>>> http://bash.org/?244321

Тогда, как понять вот это

2010 >= 1995

Тогда, как понять вот это

Тогда посчитать, сколько уязвимостей упомянуто в хедпосте. 2010 относится к первой из них.

Скорее фундаментальная ошибка генома интеловского менеджмента.

Понизь значение

#define CACHE_HIT_TRESHOLD (100)

У меня при значении выше «128» тоже начинает выдавать «Unclear», но при меншем значении работает.

Тогда посчитать, сколько уязвимостей упомянуто в хедпосте. 2010 относится к первой из них.

по неподтвержденным данным все модели с 1995 года, кроме Itanium и Atom

Данные непотвержденные. Сам ТС написал. Можно ссылку на список моделей?

благодаря отложенному выполнению команд становится не проще менять состояние кэша, а становится возможным втянуть в кэш данные из области памяти, к которой нет доступа. А дальше уже через тайм-атаку подобрать это значение, на сколько я понимаю.

Этот PoC угадывает значение данных из юзерспейса (в том же адресном пространстве). Он будет работать на почти любом OoO процессоре с кэшем. Но уязвимость не в этом. А в том, что некоторые CPU могут спекулятивно прочитать из памяти, игнорируя права. Тестировать надо на адресе из ядра или mprotect PROT_NONE на юзерспейсном адресе.

Разработчики LLVM выкатили патчи для CVE-2017-5715

https://web.archive.org/web/20180104131631/https://reviews.llvm.org/D41723

трэд на HN
>>> https://news.ycombinator.com/item?id=16070050

anonymous_incognito, добавь инфу в шапку + добавь ссылку на PoC Spectre
>>> https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9e3d4bb6

точнее, там даже есть два аргумента (сколько байт и адрес) и можно проверить, но без аргументов он ничего не демонстрирует https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9e3d4bb6#file-spec...

А теперь вопрос - а могло ли это быть умышленно? насколько реально существование утилиты от Sysinternals с каким нибудь банальным названием «hello root» запустил в браузере и «здравствуйте!». Грубо говоря во общем.

Было уже

Патчи для 98 семёрочки уже выпустили? Дайте ссылку.

Давал уже здесь: https://webcache.googleusercontent.com/search?q=cache:mqDVNP6SuXwJ:https://bl...

на 15-20 выдает процентов 90. ниже - уже вопросики, выше - больше ошибок.

по неподтвержденным данным все модели с 1995 года, кроме Itanium и Atom

Это ты к тому, что данные не были подтверждены на момент написания новости? Так в этом топике уже отписались люди со старыми моделям ЦП.

https://lkml.org/lkml/2018/1/4/348 - это не про вторую уязвимость?

Subject Re: Avoid speculative indirect calls in kernel

Этот PoC угадывает значение данных из юзерспейса (в том же адресном пространстве). Он будет работать на почти любом OoO процессоре с кэшем. Но уязвимость не в этом

Уязвимость именно в этом. JIT-код (и JS) может читать данные за пределами песочницы; ядерный код (например, через eBPF) может читать всю память в системе.

Впрочем, Intel не считает это уязвимостью.

На малых значениях есть буквы, но все-равно Unclear, много ?.

Сейчас есть патчи от спектра или это все-таки принципиально архитектурная лажа и не латается?