LINUX.ORG.RU

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

 , , , ,


9

8

Разработчики из Google Project Zero опубликовали детали уязвимостей, которые затрагивают не только процессоры Intel и ARM64, но и AMD тоже (есть сообщения, что только при включении BPF JIT в ядре, что по умолчанию выключено). Названия им дали: Meltdown и Spectre (расплавление ядерного реактора и призрак).

Meltdown позволяет приложению читать любую память компьютера, включая память ядра и других пользователей. Этой атаке подвержены процессоры Intel. Точных сведений об уязвимых процессорах нет, но скорее всего минимум начиная с Core Duo.

Spectre создаёт брешь в изоляции различных приложений и позволяет атакующему обманным способом получить данные чужого приложения. Этой атаке подвержены процессоры Intel, AMD, ARM64, Power8 и 9. По неподтвержденным данным узявимы практически все процессоры, умеющие спекулятивное исполнение кода. Для Intel это процессоры, начиная с Pentium Pro (1995 год), кроме Itanium и Atom. Есть сообщения о том, что уязвимость проверена на Pentium-M 1.5 ГГц (2004 год).

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

Уязвимостям назначены следующие CVE: CVE-2017-5753, CVE-2017-5715 и CVE-2017-5754.

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

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

Технические подробности про spectre (есть пример кода в конце файла)
Код из spectre.pdf выложенный отдельно.
Технические подробности про meltdown
Еще про meltdown
Видео, демонстрирующее утечку памяти meltdown
Технические детали для ARM-процессоров
Отчёт от Red Hat, упоминающий процессоры IBM Power как уязвимые.

UPD: Хорошая статья на русском языке про meltdown
UPD2: Продолжение про два вида Spectre

>>> Подробности

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

Singularity ★★★ ()

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
anonymous ()
Ответ на: комментарий от anonymous

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

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

Мрак.

anonymous ()

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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-го!!!!!!!!

praseodim ★★★ ()

1984

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

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

atsym ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

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

alexru ★★★★ ()

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

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

atsym ★★★★★ ()
Последнее исправление: atsym (всего исправлений: 1)

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

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

cvs-255 ★★★★★ ()

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

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

Napilnik ★★★★★ ()
Ответ на: комментарий от Napilnik

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

anonymous_incognito ★★★★★ ()

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

Какого?

anonymous ()
Ответ на: комментарий от anonymous

Плюсую.

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

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

atsym ★★★★★ ()

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.

atsym ★★★★★ ()
Ответ на: комментарий от anonymous_incognito

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

atsym ★★★★★ ()
Ответ на: комментарий от anonymous_incognito

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

atsym ★★★★★ ()
Ответ на: комментарий от anonymous_incognito

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

atsym ★★★★★ ()
Ответ на: комментарий от anonymous_incognito

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

atsym ★★★★★ ()

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

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

amd_amd ()
Ответ на: комментарий от anonymous_incognito

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

Песня!

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

atsym ★★★★★ ()
Ответ на: комментарий от atsym

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

amd_amd ()
Ответ на: комментарий от anonymous

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

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.

ckotinko ☆☆☆ ()
Последнее исправление: ckotinko (всего исправлений: 1)
Ответ на: комментарий от anonymous_incognito

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.

atsym ★★★★★ ()
Ответ на: комментарий от ckotinko

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

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

anonymous_incognito ★★★★★ ()

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

int x = 0;
double y;
if (likely(x!=0)) {
    y = atan(23143242.0);
}
atan придется досчитать даже если не хочется. а теперь мы пишем:
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);
код, который никогда не выполнится но всё же выполняется, в зависимости от значения байта который мы хотим считать, по разному тормозит. мы измеряем торможение и делаем вывод о значении байта. пример заранее говорю кривой, ибо там надо не условный переход делать, а какой нибудь синус считать - эта операция имеет разную длительность для разных значений операнда.

ckotinko ☆☆☆ ()
Ответ на: комментарий от anonymous_incognito

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

ckotinko ☆☆☆ ()
Ответ на: комментарий от anonymous_incognito

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

ckotinko ☆☆☆ ()
Ответ на: комментарий от atsym

O_o

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

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

anonymous_incognito ★★★★★ ()
Ответ на: комментарий от ckotinko

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

atsym ★★★★★ ()
Ответ на: комментарий от anonymous_incognito

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

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

ckotinko ☆☆☆ ()
Ответ на: комментарий от ckotinko

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

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

anonymous_incognito ★★★★★ ()
Ответ на: комментарий от anonymous_incognito

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

Плюсую ;-)

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

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

atsym ★★★★★ ()
Последнее исправление: atsym (всего исправлений: 1)

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

Leupold_cat ★★ ()
Ответ на: комментарий от anonymous_incognito

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

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

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

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

ckotinko ☆☆☆ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.