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

Ровно до тех пор, пока не найдут ещё один подобный баг. С учётом современных реалий - это всего-лишь дело времени.

Интересно, как в наше время все чаще и чаще стали находить баги 10 летней давности, да? Неужели погромисты стали умнее (привет, node js, php, swift, go).

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

Да чаво уж там... MS DOS наше фсйо. Мало того что переключений контекста нет, так и вообще адресное пространство едино. Заживем...

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

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

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

Каком закрытом? Я про хартблиды всякие.

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

очень-очень странный аргумент

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

Я без чтения новости уже сторонник того, что бага, что держали до самого последнего момента, надеясь что пронесет, а теперь вот, получите свои процы и поделите на 2. Как я понимаю это всё до кабилейков включительно? (в подробности не вдавался).

В ИБМ знали толк, когда PS/2, OS/2... провидцы :-)

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

чтоб ею воспользоваться, тебе вирус надо собрать сперва.

Не беспокойся, сделают и в браузере эксплойты.

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

И да, в Гипер-в у меня на десктопе крутится Шин-сервер, как десктоп для телефизора и ушатанной андроид приставки, вместо помершего ноутбука.

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

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

Подразумевается, что это формально невозможно, исходя из свойств самого языка

Если Rowhammer сделали на JS, не вижу, почему эту атаку нельзя сделать на C#.

tailgunner ★★★★★
()

Смотрю тут кто-то уже тестирует. Я обычно использую stockfish запущенный в начальной позиции, как бенч. Кол-во узлов в секунду вполне надёжный показатель.

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

В топике речь про то, что системные вызовы станут тяжелее. В 7z из системных вызовов только ввод-вывод, да и тот буферизован, то бишь разницы ты не увидишь. А нормальные тесты можешь посмотреть на форониксе.

Ну вот уже выясняется значит, что просто вычислительные задачи это не затронет или слабо затронет, хотя все-равно интересно насколько.

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

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

VKraft ★★
()

В тред врывается dk-. Расскажи, что будешь делать, если после патча фотожопе не хватит производительности.

Napilnik ★★★★★
()

Когда жабоскрипт может поиметь твой комп со всеми привилегиями. What a time to be alive! Хорошо, что у меня всегда было амуде.

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

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

openssl до сих пор используется в дебиане, например. попробуй написать им баг-репорт и посмотри, что получится. ой, уже ведь есть такой:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754513 Severity: wishlist

anonymous
()

Нормальная информация по уязвимости есть, кроме криков «ааа, мы все умрем»? Потому что по той информации, что я смог найти, каких-то фатальных последствий оно в себе не несет. Нигде с пруфами не приведено ни чтение памяти ядра, ни даже хоть какого бы то ни было адекватного примера. Самое адекватное описание по ссылке https://cyber.wtf/2017/07/28/negative-result-reading-kernel-memory-from-user-..., но там основной вывод вроде как в том, что спекулятивное исполнение действительно имеет место быть, и можно понять, что было исполнено спекулятивно, а что - нет, причем не только понять, но и повлиять; что спекулятивное исполнение нарушает собственно изоляцию user/kernel. Есть замечание о том, что можно получить _результаты_ этого спекулятивного исполнения, хоть они и были отброшены на более поздних стадиях обработки инструкции, но не упоминается, _какого рода_ эти результаты. В конце и вовсе упоминается об особенностях, связанных с виртуальными машинами. Пока что не выглядит как катастрофа, хотя хорошего, конечно, тоже ничего нет.

// Тред не читал

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

В начале обсуждения приведены ссылки на LWN, где даются результаты тестов: https://lwn.net/Articles/742404/

Умудрился не заметить, извини.

Fedora rawhide released a PTI enabled kernel (4.15.0-0.rc6.git0.1.fc28.x86_64). I did some test with it. Syscalls are much 
slower with PTI enabled.

 bench_03_getpid_vdso 2.7x slower
 bench_11_read_vdso 2.0x slower
 bench_21_write_vdso 2.3x slower

 I had used this benchmark https://github.com/arkanis/syscall-benchmark on 
an Intel i5-4200U. Of course this is only a microbenchmark. The real world 
slowdown is much less.

То есть на сисколах просадка вообще более, чем в ДВА раза!

readonly pgbench (tpch-like), 16 clients, i7-6820HQ CPU (skylake):

 pti=off:
 tps = 236629.778328

 pti=on:
 tps = 220791.228297 (~0.93x)

 pti=on, nopcid:
 tps = 198959.801459 (~0.84x)

 To get closer to the worst case, I've also measured:

 pgbench SELECT 1, 16 clients, i7-6820HQ CPU (skylake):

 pti=off:
 tps = 420490.162391

 pti=on:
 tps = 350746.065039 (~0.83x)

 pti=on, nopcid:
 tps = 324269.903152 (~0.77x)


 So yea, definitely not fun :(

Мда, не радует. Хотя и не сказать, что совсем уж плохо, могу предположить, что на десктопе и ноутах это будет, наверное, не сильно заметно. Или можно попробовать разогнать на 30% =)

Интересно, что раннее описание появилось еще в июле https://cyber.wtf/2017/07/28/negative-result-reading-kernel-memory-from-user-...

Я только не понял, эта статья всем была доступна или только сейчас открыли? Если всем, то видимо никто не чесался, до появления реально работающего эксплоита. Забавно.

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

Ладно, плохой пример. Критический баг был в bash, несколько в ядре (что-то там с памятью недавно проскакивало). Я про то, что в последние несколько лет усиленно находят бородатые «закладки». Подругому их не назвать. Ну не могут они быть просто багами. Не верю я что тогдашние пограмисты писали код, который взламывают нынешние.

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

openssl до сих пор используется в дебиане, например. попробуй написать им баг-репорт и посмотри, что получится. ой, уже ведь есть такой:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754513

Это не баг-репорт вообще и не баг-репорт на OpenSSL в частности.

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

Интересно, как в наше время все чаще и чаще стали находить баги 10 летней давности, да?

Просто процессоры 10-летней давности не так уж плохо выглядят на фоне современных, как хотелось бы. Вот и «помогают», как могут.

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

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

«Богатыри, не вы» (ц)

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

Чую, все это махинации по типу биткоина. Обиженки или диссиденты из анонимуса раскрывают закладки, а остальным кулхацкирам приходится деланно удивляться и быстро-быстро латать и кудахтать по новостным сайтам.

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

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

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

Что бы купить камушек эльбруса нужно продать свою квартиру

Да, плюс, в Эльбрусах свой товарищ майор сидит...

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

Нормальная информация по уязвимости есть, кроме криков «ааа, мы все умрем»?

Говорят, что придерживают до середины января, пока MS для винды патчем не разродится.

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

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

В железе о таком заговоре ещё не слышал.

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

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

Barracuda72 ★★
()

Как то побарабну на все эти уязвимости...

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

Про Apple что-нибудь слышно? Ато сильная половина ЛОРа опасносте.

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

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

Но лор же на айфоне! И в облаке!

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

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

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

Есть еще одна мегастранность. Вроде этой же уязвимости подвержены процы ARM64, вот это уже наводит странные мысли. Копипастили архитектуру?

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

Если кто-то не знает английский, то завтра на opennet появится более развёрнутая новость с дополнениями от Максима Чиркова, а пока он пьян.

исправил

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

А то что они множитель разблокировали и дописали K в название - чистая случайность?

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

В обычном режиме работы проблем нет.

Ну, жесткий бенчмарк легко отправит старый проц в троттлинг если ты поставить СО ориентируясь на потребление проца на базовой частоте (а проц не работает на базовой).

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

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

Есть еще одна мегастранность. Вроде этой же уязвимости подвержены процы ARM64, вот это уже наводит странные мысли. Копипастили архитектуру?

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

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

Может быть, но между прочим, к российскому импортозамещению тоже вопросы появляются, ибо процы Байкал-М - таки arm64 по архитектуре...

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

Вроде этой же уязвимости подвержены процы ARM64, вот это уже наводит странные мысли. Копипастили архитектуру?

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

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

Неужели погромисты стали умнее

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

Погромисты как раз таки умнее не стали, а скорее наоборот (присоединяюсь к привету для node js, php, swift, go). А людей, которые могут найти баги подобного уровня - остаётся всё меньше и меньше.

При этом всём, сложность железа всё растёт и растёт (как минимум чисто в плане количества тех-же транзисторов). Так что в будущем нас ждут ещё куда более эпичные баги. Может только массовый переход на более простые решения вроде ARM'а сможет хоть немного помочь.

DawnCaster ★★
()

Это поэпичнее, чем ошибка в FMA3

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