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)

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

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

Полно задач, которым нужна 100% загрузка всех ядер.

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

Так мы просто купили готовую архитектуру, а не разрабатывали сами. У нас, ЕМНИП, честно своих архитектур вообще нет, кроме одного из вариантов Эльбруса (потому что некоторые из Эльбрусов являются потомками Sun'овских SPARC, но какие - не помню уже).

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

Вах! Спасибо за ссылку. Четко написано:

The basic idea is that transitions to and from userspace are proxied
through a trampoline page which is mapped into a separate page table and
can switch the full kernel mapping in and out on exception entry and
exit respectively. This is a valuable defence against various KASLR and
timing attacks, particularly as the trampoline page is at a fixed virtual
address and therefore the kernel text can be randomized independently.

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

Barracuda72 ★★
()

спрашивают зачем тебе cpu amd вместо intel. так вот еще один +1.

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

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

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

Рабочую станцию в своё время на амд и невидии неплохую собирал... а вот лаптопы как ни посмотрю - ничего приличного из года в год не вижу.

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

у микроядер такой проблемы нет.

Это одна из причин, по которым они медленные.

tailgunner ★★★★★
()

приводит к падению производительности приложений от 5 до 30%

Короче говоря, разработчики Linux и Windows в срочном порядке пишут патч, превращающий штеуд в амд.

thesis ★★★★★
()

...требует модификации критических частей ядра и приводит к падению производительности приложений от 5 до 30%

Только недавно говорил про потребителей и про отношение к нам. Это только цветочки, дальше будет ещё смешнее. Что это значит? «Будешь на старом железе - снизим скорость. Необновляться не сможешь в онтопике. Бегом за новой железякой!!!» - сказали они.

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

Уговорил. С тебя толкование всех этих цифр.

7z b вычисляет скорость (KiB/s) и как-то это пересчитывает в MIPS для разных случаев компрессии и декомпресси, в конце вычисляет итог как среднее.

На глаз, опять же, проц заметно сильнее нагружается в первом случае.

Хех, у тебя вообще получилось, что патч pti УВЕЛИЧИЛ производительность на 1-2%! Если конечно не перепутал где что. Возможно, эффект из-за разницы в версиях компиляторов и/или ключей оптимизации.

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

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

Хотел вот собрать себе ПК на E5-2660v2. Теперь надо на Ryzen 7 собирать. Вдвое дороже.

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

Это только цветочки, дальше будет ещё смешнее. Что это значит? «Будешь на старом железе - снизим скорость. Необновляться не сможешь в онтопике. Бегом за новой железякой!!!» - сказали они.

«Сетевой нейтралитет ненужен. Мы сами знаем куда перенаправить тебя. Если захочем, то вообще не пустим тебя в интернет.» ,- сказали они.

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

блин, да что там «отрисовывать»-то???? ну что? на этих смартфонах картинку с иконками отрисовывать?

Например красивую анимацию отрисовать с частотой 120 FPS.

софт там говно и потому жрёт ресурс.

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

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

Не, я в курсе, что такое ASLR, и, вроде как, чувак пишет, что сабжевая уязвимость и используется для ее (рандомизации) обхода. Откуда я сделал вывод (возможно, не такой уж обоснованный), что раз уж эта уязвимость может быть использована для обхода ASLR, то особой опасности она для меня как для домашнего юзера не несет - слишком специфичный юзкейз, требующий, к тому же, наличия еще одного эксплоита для извлечения какой-либо реальной выгоды из другой уязвимости ядра. То есть, в принципе, это плохо, конечно, но уровень примерно тот же, что и возможность для вора разглядеть форму замочной скважины от входной двери в квартиру. Те, кто сможет по памяти ее воспроизвести (и подобрать ключ к другим замкам) в квартиру к обычному человеку не полезут - не то соотношение риск/выгода, а прочие воспользоваться этим никак не смогут. На каком-нибудь важном и высоконагруженном сервере да, это критично.

Barracuda72 ★★
()

работайте, братья

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

и, вроде как, чувак пишет, что сабжевая уязвимость и используется для ее (рандомизации) обхода.

Не вижу, где он это пишет (в цитате, которую ты привел, этого нет).

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

Окей, я это додумал сам, но это достаточно очевидно. Он пишет, что запиленный им фикс аналогичен тому, который был ранее сделан для x86, и направлен на предотвращение атак супротив KASLR. Логично было предпололжить, что сабжевая уязвимость направлена в том числе и на обход ASLR (конечно, возможно, что не только для этого).

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

Ждем, пока на opennet прочитал обратное мнение

Шум подняли из-за ничего, по сути. Перевод тоже не блещет, впрочем. По данным других источников, проблема проявляется в том, что теперь одна VM может получить доступ к памяти другой VM, исполняющейся на том же компьютере, в том числе и к памяти ее ядра. Отсюда и столько криков со стороны Amazon EC2, Google Cloud, результаты тестов из СУБД, трепета по поводу производительности и тп. То есть злоумышленник, купивший VM на том же амазон, теоретически (!!! теоретически) может выудить данные со свех других VM, которые крутятся с ним на одной ноде кластера. Доступа к памяти ядра в хост-системе он не получит. Обычные польовательские программы на обычных пользовательских десктопах это никак не затронет, и все эти страшилки про JS, читающий память ядра, тоже бред. А информация по поводу предвыборки инструкции, которая якобы сначала может выполниться, а потом уже пройти проверки безопасности, и вовсе относится к процессорам AMD и вообще носит характер «мы тут подумали, а вдруг такое возможно». Короче, шума много, толку ноль. Гугл с Амазоном потеряют пару миллиардов, а обычным людям, в общем-то, пофигу.


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

Не любой и не рут. Если очень просто (и неправильно) объяснять, то хитрым образом составив список ассемблерных инструкций для обращения к памяти, атакующий может определить, какая информация лежит в кэше процессора (не содержимое этой информации! только сам факт ее наличия) и по какому адресу она расположена в пространстве ядра. Атака против ASLR, короче говоря.

Еще говорят, что патч на wine плохо влияет...

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

Почему обратное? Вроде то же самое:

Атака против ASLR, короче говоря.

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

Полно задач, которым нужна 100% загрузка всех ядер.

Речь о загрузке транзисторов, а не ядер.

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

А информация по поводу предвыборки инструкции, которая якобы сначала может выполниться, а потом уже пройти проверки безопасности, и вовсе относится к процессорам AMD

Это вранье. Соответственно, остальной части комментария я бы тоже не доверял.

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

Гугл с Амазоном потеряют пару миллиардов, а обычным людям, в общем-то, пофигу.

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

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

Я думаю, что ничего особенного с облаками и vps не случится. Даже падение производительности на 30% для них неприятно, но вряд ли очень сильно критично, потому что запас на пиковые нагрузки никто не отменял, а он и до 100% доходит.

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

В прошедшем году владельцы интелов у Санта-Клауса/Деда Мороза, похоже, попали в «список плохих детишек».

Скорее Таненбаум и Бабаян - в списки хороших.

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

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

Зато базы данных должны сильно просесть и веб-сервера тоже. Играм и числодробилкам вообще однопользовательской системы хватать должно.

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

Для линукса это неактуально, пока программы устанавливать из официальных репозиториев, а на винде и не такие анальные зонды.

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

Так крику подняли, будто чуть ли не любой JS-сценарий теперь ядро на лету патчить сможет.

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

Да, если верить в теории заговора, это вообще может быть умышленное запланированное устаревание процессоров.

Это не теория заговора, а простая закономерность капиталистического рынка. Про это, в свое время, писал В.И.Ленин. А то, что хомячки лора уже визжат, что нужно апгрейдится-тому доказательство.

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

Это не так опасно как эта дырка по их мнению. Криков было меньше.

anonymous
()

Очень плохо, а что теперь делать?

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

Куплю новый комп

А толку то :D Он тоже будет тормозить

Deleted
()

После этой новости у меня возник мощный непроходящий баттхерт, и продолжается уже 5 часов. Это нормально?

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

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

+1. Хоть один адекватный комент в потоке гогна на девяти страницах.

Odalist ★★★★★
()

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

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

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

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

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

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

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

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

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