Fück My Life:

https://www.youtube.com/watch?v=bReA1dvGJ6Y

Разработчики Google Chrome встраивают защиту от плохого JS кода прямо в браузер: https://sites.google.com/a/chromium.org/dev/Home/chromium-security/ssca

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

Спасибо Intel за наше счастливое настоящее.

Linus уже высказался в своём духе:

From	Linus Torvalds <>
Date	Wed, 3 Jan 2018 15:51:35 -0800
Subject	Re: Avoid speculative indirect calls in kernel
	

On Wed, Jan 3, 2018 at 3:09 PM, Andi Kleen <andi@firstfloor.org> wrote:
> This is a fix for Variant 2 in
> https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html
>
> Any speculative indirect calls in the kernel can be tricked
> to execute any kernel code, which may allow side channel
> attacks that can leak arbitrary kernel data.

Why is this all done without any configuration options?

A *competent* CPU engineer would fix this by making sure speculation
doesn't happen across protection domains. Maybe even a L1 I$ that is
keyed by CPL.

I think somebody inside of Intel needs to really take a long hard look
at their CPU's, and actually admit that they have issues instead of
writing PR blurbs that say that everything works as designed.

.. and that really means that all these mitigation patches should be
written with "not all CPU's are crap" in mind.

Or is Intel basically saying "we are committed to selling you shit
forever and ever, and never fixing anything"?

Because if that's the case, maybe we should start looking towards the
ARM64 people more.

Please talk to management. Because I really see exactly two possibibilities:

 - Intel never intends to fix anything

OR

 - these workarounds should have a way to disable them.

Which of the two is it?

                   Linus

Для тех кто не понял: текущие патчи безусловно врубили KPTI для всех процессоров Intel, что может означать, что у компании нет силикона/архитектур, в которых эта ошибка исправлена!

Что может означать, что Cannon Lake выйдет с этой дырой, а Ice Lake может быть задержан до 2 половины 2019 года.

Мрак.

Сопли под крышкой, дыры в логике. Слава Флагману ИТ!

P.S. в новости нету информации о том на сколько сильнее IO тормозит с фиксом.

So, Intel, FUCK YOU!

Это какой-то песец, каких еще не было

https://meltdownattack.com/

Which systems are affected by Meltdown?

Desktop, Laptop, and Cloud computers may be affected by Meltdown. More technically, every Intel processor which implements out-of-order execution is potentially affected, which is effectively every processor since 1995 (except Intel Itanium and Intel Atom before 2013). We successfully tested Meltdown on Intel processor generations released as early as 2011. Currently, we have only verified Meltdown on Intel processors. At the moment, it is unclear whether ARM and AMD processors are also affected by Meltdown.

ВСЕ (за исключением Itanium и Atom) процессоры Intel с 1995-го года. 1995-го!!!!!!!!

1984

Видел трэд на одной странице.

P.S.: Чёт ржу.

Для тех кто не понял:

Линус беспокоится за включение AMD в этот патч, и совсем не за будующие процессоры Intel.

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

Напомню, что пользователи ежедневно запускают чужой код на своих компьютерах, посещая веб сайты с JavaScript (>99%), поэтому применение патча обязательно, если вы дорожите своими данными. Есть PoC (п.4.3) , демонстрирующий атаку с этой уязвимостью через JavaScript.

Запретить JavaScript в интернете - и баг уже не такой и критический был бы ;-)

Может быть это

не уязвимость, а бэкдор?

Детали от разработчиков ARM

anonymous_incognito, добавь в текст новости
>>> https://developer.arm.com/support/security-update

Трэд на HackerNews...

... набирает обороты
>>> https://news.ycombinator.com/item?id=16065845

Добавил

Эксплоит, эксплуатирующий Meltdown позволяет читать память ядра со скоростью 2000 байт в секунду на процессоре Intel Xeon архитектуры Haswell.

Что-то медленно, диалап какой-то, запаришься с такой скоростью 32 гига выкачивать - информация будет быстрее генерироваться чем качаться. Помогите Интелу, напишите патч для ускорения скачивания!

В PoC упоминается, что это только пруф уязвимости и есть возможности ускорения считывания. Но и в таком виде это безусловно угроза, не требуется считывать все 32Гб памяти, если примерно известно, где в памяти лежат пароли.

применение патча обязательно

Какого?

Плюсую.

применение патча обязательно

Где патч, который нужно обязательно применить?

Прототип атаки для Windows (на C++)

https://twitter.com/SamieONeill/status/948714555449978885

Azure "ушёл в reboot"

https://azure.microsoft.com/en-us/blog/securing-azure-customers-from-cpu-vuln...

With the public disclosure of the security vulnerability today, we are accelerating the planned maintenance timing and will begin automatically rebooting the remaining impacted VMs starting at 3:30pm PST on January 3, 2018. The self-service maintenance window that was available for some customers has now ended, in order to begin this accelerated update.

https://lwn.net/Articles/742404/

И ещё на C++ и ASM
>>> https://twitter.com/pwnallthethings/status/948693961358667777

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

Так добавил вроде.

Это тоже самое.

А когда в репах появится - вот в чём вопрос...

Гентушники уже откомпилировали в предыдущей новости.

Там другой пастосервис (зеркало) использовался.

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

посещая веб сайты с JavaScript

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

Между прочим, запустил код из spectre.pdf https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9e3d4bb6 - работает. (Для компиляции надо немного пропатчить строчку с #define - убрать скобки)

Зеркало на Github'е
>>> https://github.com/turbo/KPTI-PoC-Collection

попробую без нее

Вот патч

$ sudo apt get install links2

Ох, и жаркий же будет январь в этом году ;-)

Песня!

Кабы небыло зимы в городах и сёлах
Никогда б не знали мы этих дней веселых ...

такой патч не нужен, у меня свой патч - luakit, прописал в конфиг «noscript» не отключая «userscript», лор вроде не изменился только шрифты какие то нетакие, а в kraken тесте вместо привычных 3500 - 2100 набрало это ж голый javascript - чего он так полетел отрубленный на половину? поеду так дальше...

а вот теперь понятно что там такое произошло. спалил линус всю контору одним предложением.

A *competent* CPU engineer would fix this by making sure speculation
doesn't happen across protection domains. Maybe even a L1 I$ that is keyed by CPL.

линус в процах не понимает, но спалил знатно. а я то думал, зачем они анмапают таблицы для MMU. это же никак не связано.

короче, смотрите что происходит.

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

https://news.ycombinator.com/item?id=16066687

So what exactly are they going to do about spectre? Seems pretty unstoppable from what I can see.

Can they disable speculative exec completely for sensitive boxes or is this too baked in?

There's no mitigation. We'll need new CPUs.

Meanwhile, don't ever run untrusted code in the same process as any kind of secret. Better yet, don't ever run untrusted code.

https://twitter.com/pwnallthethings/status/948735946308116480

Where does the claim that the «Spectre» Intel bug «can't be fixed» come from?

All of these can be mitigated. It's just what performance trade-off you're willing to take to get it.

линус в процах не понимает

Он какое-то время работал в Transmeta в команде разработчиков процессора над ядром, исполняющим микрокод. Так что думаю, что он понимает поболее многих.

первая уязвимость такова: дело в том, что заспекуленые но уже ненужные команды должны «доспекулироваться» до конца. то есть

int x = 0;
double y;
if (likely(x!=0)) {
    y = atan(23143242.0);
}

int x = 0;
double y;
time_t times[256];
for(int n = 0; n < 256; ++n) {
   t1 = get_time();
   do_1000000times {
      if (likely(x!=0)) {
          if (readbyte(address)==n)
            y = atan(23143242.0);
      }
   }
   t2 = get_time();
   times[n] = t2;
}
n = find_greatest_time(times);
printf("byte at address %p = %02x\n",address,n);

ну видно что он не понимает всё таки. указание CPL в L1I никак не поможет, а наоборот всё запутает. тут штука в том, что инструкция юзермода может переждать время перехода в режим ядра и сработать уже там.

то есть я уверен что там можно ПИСАТЬ в память.

O_o

Вот это прикол будет, если сейчас выяснится, что нормальных патчей на уровне ОС вообще не возможно выпустить. Или падение производительности будет не 30% а куда хуже, причём баг вообще во всех процах, где есть эта фича со спекулятивным исполнением, то есть, начиная с Pentium Pro.

Между прочим, что-то глухое молчание про процессоры Power, там ведь вроде тоже спекулятивное исполнение имеется?

Запуль тогда своё решение/патч на Github/Pastebin/etc. чтобы можно было ссылаться

Вот это прикол будет

/me скрестил пальцы

Meltdown и Spectre — названия двух атак на процессоры Intel/AMD/ARM64/Power (комментарий)

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

возможно,это можно пофиксить микрокодом.

то есть я уверен что там можно ПИСАТЬ в память.

Вот уж действительно задумаешься, в вдруг в самом деле это «фича» для АНБ? Потому что, становится даже странным как могли не подумать даже не о безопасности, а о целостности данных. Там же для спекулятивного исполнения кода в ветках конвеера были придуманы замещающие регистры (копии РОН), об этом ещё писалось в книжках по оптимизации кода для P-I и PPro.

Вот уж действительно задумаешься, в вдруг в самом деле это «фича» для АНБ?

Плюсую ;-)

Meltdown и Spectre — названия двух атак на процессоры Intel/AMD/ARM64/Power (комментарий)

Странно, что Сноуден молчит по этому поводу до сих пор
https://twitter.com/Snowden

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

да херню в книжках пишут. там сами не знают что несут.

вот пень-2. у него 5 конвейеров в каждом по 8 инструкций «в полете». итого 40. у инструкции есть результат - это те самые «40 переименовываемых регистров» о которых пишут ебланы в книжках. кроме того, есть и сами регистры, они живут отдельно.

когда инструкция А стартует, она сперва смотрит - есть ли операнды «в полете», если нужного нет, читает его из регистрового файла. если есть - ставит зависимость от инструкции Б где операнд вычислен. плюс есть угловые ситуации типа целый регистр после байтового. когда инструкция Б от которой зависим завершилась, она нас уведомляет и присылает свой результат. когда в А соберутся все операнды, она становится «готовой» и сама будет послана когда нибудь в АЛУ. по завершению инструкции она идет в retirement где собственно и записываются её результаты.

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