LINUX.ORG.RU

Разработчики Linux и Windows работают над закрытием аппаратной уязвимости процессоров Intel

 , , ,


10

8

Ошибка проектирования всех процессоров Intel, выпущенных за последние 10 лет, заставила разработчиков Linux и Windows в срочном порядке перерабатывать схему разделения адресных пространств ядра и пользователя, брешь в которой вызвана этой ошибкой. По известным сейчас данным, переработка требует модификации критических частей ядра и приводит к падению производительности приложений от 5 до 30% (чипы Intel 2010 года и новее имеют в своём арсенале возможности, чтобы сократить это падение).

Суть уязвимости, скорее всего, заключается в том, что спекулятивное исполнение кода косвенно нарушает контроль доступа, и это позволяет приложению «видеть» содержимое защищенного адресного пространства ядра (раннее описание). Детали уязвимости находятся под эмбарго до выпуска исправлений, который намечается на середину января 2018, когда выйдет новое ядро Linux и ежемесячное обновление безопасности для Windows.

Для решения проблемы разработчикам ядер пришлось полностью разделить память ядра и память пользовательских процессов, однако такое решение приводит к серьёзному падению производительности из-за необходимости сброса части кэша транслированных виртуальных адресов (TLB) при входе в ядро.

Разработчики ядра Линукса в шутку предлагали следующие аббревиатуры для новой модели разделения памяти ядра и пользовательских процессов: User Address Separation (*_uass) и Forcefully Unmap Complete Kernel With Interrupt Trampolines (fuckwit_*), однако остановились на Kernel Page Table Isolation (kpti_*).

Компания AMD утверждает, что её процессоры уязвимости не подвержены.

Обсуждение патча на LWN, с результатами тестов.

Общие подробности от издания The Register

>>> Технические подробности, демонстрационный код PoC

★★★★★

Проверено: tailgunner ()
Последнее исправление: anonymous_incognito (всего исправлений: 6)

Ответ на: комментарий от BruteForce

IntelME недостаточно?

Возможно, что и недостаточно. Смотря для чего и в каких условиях применять, например, IntelMe никак не поможет, если комп отключен от интернета. В тоже время есть примеры успешных атак на offline, как с stuxnet против Ирана.

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

Ее можно решить только обновлением микрокота (и то не факт что возможно). Грубо говоря проблема в том, что суперскаляр не знает про виртуальную память, а блок управления памятью не знает про суперскаляр. Тупое отключение суперскаляра даст как раз 30% падение производительности. Более умное решение - отключение суперскаляра (или перезапись памяти) только там где происходит переключение контекста.

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

Я могу бесплатно решить эту проблему просто поставив ARM.

ARM64 тоже уязвим. Не подвержен подобным багам в принципе только итаник и эльбрус.

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

Установил проприетарный драйвер для микрокода? Молодец! Зонды от интела добавляются и обновляются прямо в биосе. Откатить невозможно.

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

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

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

спекулятивное исполнение действительно имеет место быть, и можно понять, что было исполнено спекулятивно, а что - нет, причем не только понять, но и повлиять; что спекулятивное исполнение нарушает собственно изоляцию user/kernel. Есть замечание о том, что можно получить _результаты_ этого спекулятивного исполнения, хоть они и были отброшены на более поздних стадиях обработки инструкции, но не упоминается, _какого рода_ эти результаты.

Этого уже достаточно. Просканировать память ядра можно. Значит найти что-то вроде GDT/LDT можно. Их структура и так известна, так что даже не зная полного значения их можно «поправить» и получить уже нормальный доступ к памяти ядра

Kuzz ★★★
()

Детали уязвимости находятся под эмбарго до выпуска исправлений

Хахахаха :-) Прям аж страшно :-) Лол :-)

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

Штеуд сам по себе зонд. Вот если баг зарыт глубоко в архитектуру все становится вообще весело. Штеуду придется воскрешать Итаник, а АМД - покупать лицензию на Эльбрус. Ну и сотни тысяч быдлокодеров отправятся на улицу.

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

Я могу бесплатно решить эту проблему просто поставив ARM. x86 очень устаревшая архитектура, костыль на костыле и много зондов.

И какой же ARM обгонит на однопоточном бенчмарке Intel Core i7 8800K разогнанный до 5.3 GHz? Или Xeon Platinum на многопоточном? Если нужна производительность, у Intel альтернатив на рынке почти нет.

Legioner ★★★★★
()

На новом ядре, с патчем:

➜ zgrep ISOL /proc/config.gz 
CONFIG_MEMORY_ISOLATION=y
CONFIG_PAGE_TABLE_ISOLATION=y

# int13h @ homepc in ~ [19:10:38]
➜ 7z b

7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,4 CPUs Intel(R) Core(TM) i5-4460  CPU @ 3.20GHz (306C3),ASM,AES-NI)

Intel(R) Core(TM) i5-4460  CPU @ 3.20GHz (306C3)
CPU Freq:  3383  3388  3384  3418  3423  3423  3417  3423  3419

RAM size:    7676 MB,  # CPU hardware threads:   4
RAM usage:    882 MB,  # Benchmark threads:      4

                       Compressing  |                  Decompressing
Dict     Speed Usage    R/U Rating  |      Speed Usage    R/U Rating
         KiB/s     %   MIPS   MIPS  |      KiB/s     %   MIPS   MIPS

22:      13670   327   4071  13298  |     157238   401   3345  13415
23:      13373   332   4109  13626  |     155027   401   3348  13414
24:      13200   335   4237  14193  |     152550   400   3347  13392
25:      13092   336   4445  14948  |     150457   400   3350  13390
----------------------------------  | ------------------------------
Avr:             332   4216  14016  |              400   3348  13403
Tot:             366   3782  13709

# int13h @ homepc in ~ [19:11:13]
➜ 

На старом ядре, без патча:

# int13h @ homepc in ~ [19:06:05]
➜ 7z b
 
7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,4 CPUs Intel(R) Core(TM) i5-4460  CPU @ 3.20GHz (306C3),ASM,AES-NI)
 
Intel(R) Core(TM) i5-4460  CPU @ 3.20GHz (306C3)
CPU Freq:  3099  2938  3026  3210  3226  3187  3191  3273  3193
 
RAM size:    7680 MB,  # CPU hardware threads:   4
RAM usage:    882 MB,  # Benchmark threads:      4
 
                       Compressing  |                  Decompressing
Dict     Speed Usage    R/U Rating  |      Speed Usage    R/U Rating
         KiB/s     %   MIPS   MIPS  |      KiB/s     %   MIPS   MIPS
 
22:      13328   323   4016  12966  |     144525   376   3283  12330
23:      12863   339   3864  13107  |     141355   378   3233  12231
24:      14164   351   4344  15230  |     135173   369   3213  11866
25:      13307   356   4266  15194  |     137796   379   3232  12264
----------------------------------  | ------------------------------
Avr:             342   4123  14124  |              376   3240  12173
Tot:             359   3681  13148
 
# int13h @ homepc in ~ [19:06:38]
➜ uname -a
Linux homepc 4.14.10-1-ARCH #1 SMP PREEMPT Fri Dec 29 20:17:35 UTC 2017 x86_64 GNU/Linux
int13h ★★★★★
()
Последнее исправление: int13h (всего исправлений: 1)

Печально это, особенно учитывая тот факт, что у меня и на десктопе и на ноуте Intel, а на ноуте ещё и очень энергоэффективный, но не очень мощный.

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

Если нужна производительность...

Тем, кому это нужно, знают про POWER.

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

Кинцо можно смотреть без нажатия кнопки Х и ресурсов для этого нужно гораздо меньше. Ну и графоний лучше. Твои гигагерцы не нужны.

anonymous
()

Right now with the big mysterious security vulnerability causing the rush of the x86 Page Table Isolation work that landed in the Linux kernel days ago, it's believed to be a problem only affecting Intel CPUs. But at least for now the mainline kernel is still treating AMD CPUs as «insecure» and is too taking a performance hit.

Besides my initial benchmarks of the performance impact as a result of this x86 workaround in the Linux 4.15 kernel, I've been working on various other tests since yesterday and one of them was just seeing what happens on AMD hardware.

Back on 26 December is when Tom Lendacky of AMD posted a patch to confirm this PTI problem shouldn't affect the company's processors — at least with what information is currently known. Lendacky wrote, «AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault.»

But over one week later, that patch has yet to be merged to the mainline kernel. When booting the Linux 4.15 kernel on an AMD EPYC box, indeed, for now the AMD CPU is still treated with a bug of «insecure_cpu.»

An immediate workaround at least until the AMD patch lands where PTI isn't applied to AMD CPUs is by booting the kernel with the nopti kernel command-line parameter. This can also be applied to Intel systems too on a patched kernel if wanting to regain the performance and are not too concerned about this vulnerability.

In affected benchmarks (those making use of a lot of system calls, context switches, etc), indeed AMD EPYC faces a performance penalty similar to Intel. I'll have more test data to share on Wednesday. Hopefully more details on the underlying vulnerability come to light soon to really know if AMD CPUs have any chance of being affected and other details.

https://www.phoronix.com/scan.php?page=news_item&px=x86-PTI-EPYC-Linux-4....

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

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

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от DNA_Seq

Ну да, амд щас закопает свой райзен и пойдет покупать кота в мешке. Насмешил.

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

А чо без патча со сбросом частоты проца?

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

В этом тесте полтора syscall'а за всё время выполнения, потестируй лучше I/O.

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

Удвоил вопрос зачем костылить в ядре если есть микрокод

Наверное в микрокоде делать нечего или не хотят ломать то, что работает.

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

да ни о чем, костыль только сейчас вышел

Available kernel symlink targets:
  [1]   linux-4.14.11-gentoo *

*
* Security options
*

Remove the kernel mapping in user mode (PAGE_TABLE_ISOLATION) [Y/n/?] (NEW) 


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

Удвоил вопрос зачем костылить в ядре если есть микрокод

О баге известно уже несколько месяцев. Обновления микрокода не выпущено. На что это может намекать?

да ни о чем

okay.jpg

костыль только сейчас вышел

Этот костыль не меньше двух месяцев в разработке.

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

О баге известно уже несколько месяцев. Обновления микрокода не выпущено. На что это может намекать?

на то, что вице-президент интел имел несколько месяцев на то чтобы продать свои акции?

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

А на планшетах и прочих дебильниках 64 бита нафига?

Чтоб налогоплательщики делали селфи в 4к, 32к, 128к, и т.д., чтоб твоя мамка получала пенсию и подлечивалась, чтоб тебя, нищука, кормить.

anonymous
()

Тем временем акции уже поползли: https://www.bloomberg.com/amp/news/articles/2018-01-03/amd-soars-after-rival-...

The report hit Intel shares, which fell as much as 3.8 percent, the most since April, and gave a boost to rival Advanced Micro Devices Inc., which surged as much as 7.3 percent to $11.78 Wednesday. An Intel spokesman declined to comment.

KennyMinigun ★★★★★
()
Последнее исправление: KennyMinigun (всего исправлений: 1)
Ответ на: комментарий от Kuzz

Просканировать память ядра можно.

Об этом пока ничего достоверно неизвестно. Ждем подробностей.

Значит найти что-то вроде GDT/LDT можно.

Всего год назад в ядро впилили UIMP. До этого физический (впрочем, не логический) адрес GDT/LDT был доступен без всяких прыжков на граблях - sgdtr/sldtr не являются привилегированными инструкциями. Как его отобразить в пространство пользователя - другой вопрос. И, кстати, не факт, что GDT/LDT вообще отображены даже в пространство ядра - они ему, по-хорошему, и не нужны после начальной инициализации. Кстати, ЕМНИП, LDT и вовсе используются довольно редко и дескрипторы не всех типов сегментов там можно хранить.

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

Больше скажу, и значения известны. А вот пруфов на возможность «поправить» пока не подвезли. Так что ждем.

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

Ага, вовремя CEO интела успел продать свои акции 29 ноября.

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

чтоб тебя, нищука, кормить.

Эта Ванга сломана, замените.

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

Подумай ещё раз. Теперь для 99% пользователей апгрейд даст от 5 до 50% прибавки производительности.

tonko

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

Печально это, особенно учитывая тот факт, что у меня и на десктопе и на ноуте Intel, а на ноуте ещё и очень энергоэффективный, но не очень мощный.

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

Так что расслабляем булки и не волнуемся

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

Для Электроника Д3-28 была ОС ВТ-МХТИ с прекрасным компилятором ЯВУ

Мсье, как раз таки ОС ВТ-МХТИ - это уже махровый новодел конца 80х. Который к тому же не на все модели Д3-28 становился. Я же за педали этого пылесоса сел в 85м, когда ОС для этого «калькулятора» еще не было в природе. Так что «слишком много кушать» это для вашего молодого поколения ;)

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

На GPRS

Слишком щедро. На CSD, 9600 бод. 19 р/минута. С почасовой тарификацией.

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

У AMD нет этой проблемы, это не проблема x86, это проблема внутренней говнореализации микроархитектуры интела. Которую еще и в ARMV8 умудрились притащить.

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

На opennet сказали что десктопы этой уязвимости не подвержены

С этим утверждением можно было бы поспорить, но даже если так, то обновления со снижением производительности придут всем сразу, и на серверы, и на десктопы, слава унифицированным ОС!

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

Палец разминает.

А потом выдаст «Fuck you, AMD. Intel pays more, so the slowdown will be for everyone!»

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

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

Интерпретатор JS из браузера уже выпилил?

anonymous
()

10 страниц, Штеуд торт. А на следующий НГ сладкое ожидается?

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

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

А как тут завязана виртуализация?

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

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

Вголос почему-то.

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

Идиот, а ты веб без JS смотришь?

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

Он ходит в веб через curl/telnet.

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

в ryzen они под вопли про «элементы исскусственного интеллекта» вхерачили в проц блок для «ускорения» бенчмарков. он как бы узнает код бенчмарков и впихивает «подсказки» чем заменить те или иные инструкции чтоб перло быстрее.

А что мешало, как у nvidia, в драйвере это реализовать?

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