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)

А вот что думают наши коллеги из проекта FreeBSD: https://forums.freebsd.org/threads/63955/

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

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

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

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

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

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

Придут и случайно у всех сбойнут, все станет раком. Не будет перешиваться и не полезет в сеть. Восстание машин? А потом ...

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

Послушать бы теперь сказки от Oracle software in silicon, IBM POWER.. %-)

Для полнейшего секьюрити в силиконе только fabric должен быть. А процессорная логика в виде битвари заливаться. Типа как в FPGA.

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

Патч меняет всего две строки и проще пареной репы, но прошла уже неделя а он до сих пор не смёржен...

Может, потому что быдлокод? Типа, все процессоры, бывшие и будущие, кроме АМД, плохи, а вот АМД по-любому молодцы.

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

А вот что думают наши коллеги из проекта FreeBSD: https://forums.freebsd.org/threads/63955/

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

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

А вот что думают наши коллеги из проекта FreeBSD: https://forums.freebsd.org/threads/63955/

По ссылке жир. Нет, ЖЫР!!!

But the most amazing thing is that this exploit technique was known already since Jan. 1967, 51 years ago. Yes, 1967. No typo. http://ieeexplore.ieee.org/document/5392028/?reload=true

Типа еще тогда для ibm 390 было известно.

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

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

Кто «они»? И зачем накладывать патч, если на фре не крутятся фермы виртуализации, от кого спасать админов веб-серверов и БД, которые с завозом патчей в линупс будут хихикать и тыкать палочкой? )

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

Погуглили бы чтоль как интел рубило все инструкции на не своих камнях компилятором..

Выхлоп file мне лично не говорит ничего. как и всем. А вот IDA прогнать бинарник на предмет не очень правильного использования cpuid стоило бы.

И кстати да, разницу на открытом бенчмарке встудию.

к примеру taubench. или на худой конец hpl.

и собирать с march=generic, если что.

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

У меня на даче для таких случаев есть Pentium 4 2003 года, надо только с него плесень стереть.

Уверен, никакой замедляющий патч не сделает более-менее современный ЦПУ хуже P4.

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

Ждем подробностей.

Это да, без подробностей можно только ванговать)

LDT и вовсе используются довольно редко

Call gate изобразить можно, а этого достаточно.
Вроде, разные системы виртуализации используют (VMWare использовала, как минимум). Может, потому часто упоминаются всякие облачные хостеры.

Об этом пока ничего достоверно неизвестно.
А вот пруфов на возможность «поправить» пока не подвезли.

Я исхожу из того, что самый простой «результат» исполнения - да/нет. Т.е. для операции сравнения - нашли или нет нужный адрес памяти.

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

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

Не всякий не-Intel-евский процессор является процессором AMD

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

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

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

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

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

Именно по таким причинам акции и ползут. Реальное состояние никому не интересно

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

Не всякий не-Intel-евский процессор является процессором AMD.

В том-то и дело, что там процессор смотрят не по интеловости, а по амдешности.

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

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

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

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

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

ну тут сейчас сложно сказать.

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

потому что очередь предвыборки команд имеет 32 слота. но по документации их 28. 32-28=4. 4 это колво команд, декодируемых и выбираемых из очереди железом. это и есть тот самый кэш микроинструкций, ускоряющий короткие циклы, который интел рекламировал в коре_и7.

очевидно, для тех кто делал свой проц или хотя бы мучил FPGA что когда декодеру не хватает данных на втык 4х команд, он втыкает nopы. так вот, оказалось что когда цикл очень короткий, то кэш «работает». но как показали падения ocaml он уже работает «не так».

ckotinko ☆☆☆
()

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

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

кол-л-е-гг-г-аа не тррясите машину времени, 360-же!

Хотя один хрен, посадить ЛОРовца за пульт, ничего не разберет, зато , как голубь, в шахматы сыграет и в Толксы разнесет %-)

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

не, поваров достаточно кормить только тем, что они приготовили. за три года научатся :)

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

Есть лишние деньги на вкусную еду - покупай нормальных поваров ;)

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

Шо, таки сама всё всё пишешь? И браузер в том числе?

Вот интересно пройдёт ли этот трюк в webassembly, который так активно сейчас рекламируют хипсторам-вебмакакам.

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

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

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

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

хотя идея написать свой мне нравится. но времени пока нет.

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

Должен пройти.

вебмакакам

Это врятли. WebAssembly же для запуска кода сгенерированного нормальным языком, типа c++.

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

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

Это нормальный, естественный, рыночный процесс. Пересечение спроса и предложения. Где спрос более требовательный и материально обеспеченный, туда программисты другого уровня предлагаются.

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

Оно конечно чаще, но там в коде интерфейса силами дизайнеров гугла заложен раздражающий 0,3 секундный лаг при нажатии некоторых кнопок. Причём для максимальной плавности этого лага задействована видеокарта. А выполнение команды пользователя соответственно начинается только после выполнения этого лага.

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

Да тут дело не в том из чего сгенерировано, а в том что WA по сути виртуалка и есть.

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

Вроде, разные системы виртуализации используют

Тут ХЗ, я не спец. Помню, на заре x86_64 был кипиш по поводу того, что из-за отказа от сегментации не работал VirtualBox в режиме софтварной эмуляции c 64-битным гостем. Потом AMD сегментацию частично вернули, что позволило реализовать полностью софтварную виртуализацию. Intel так этого и не сделали. Но это было давно и я могу ошибаться.

Я исхожу из того, что самый простой «результат» исполнения - да/нет

Результат операции сравнения на x86 - изменение регистра EFLAGS/RFLAGS (ЕМНИП, сравнение выполняется как вычитание), которое, естественно, не фиксируется ввиду непрохождения инструкцией проверок защиты. Где там промежуточный результат летает - да пес его знает. Я понял из статьи на cyber.wtf то, что технически можно по времени отклика детектировать наличие в виртуальном адресном пространстве ядра тех или иных диапазонов адресов, например, но понять, что в них лежит, вроде бы как напрямую нельзя - можно только попытаться сконструировать некоторую последовательность команд, типа

mov $KernelAddressToTest, %rax
mov 0x0(%rax), %rbx
mov 0xSomeUserSpaceAddress(%rbx), %rax

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

Действительно, чем гадать - лучше подождать подробностей.

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

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

но при этом результат почему-то от быдлокодеров отличается an mass в пределах статпогрешности =(

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

вот-вот. потому я стараюсь избегать использования браузера, при возможности. или использовать прямые запросы или консольные браузеры без скриптов.

я уже пересмотрела много разных браузеров и нигде меня не устроила ни реализация, ни безопасность, ни общий объём пожираемых ресурсов. и, главное, что тенденции всё хуже и хуже. я понимаю, что настанет день, когда использование браузера на моём компе станет просто невозможным. видимо, надо потихоньку начинать писать свой :) ну или брать elinks и доводить его до ума. ну или сваливать на zeronet, хотя там тоже скрипты и я пока не придумала, как там можно было бы обойтись без них.

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

но при этом результат почему-то от быдлокодеров отличается an mass в пределах статпогрешности =(

Не, всё нормально. En masse может в той же самой требовательной конторе был говнистым, но костяк - толковые профессионалы. Если же и костяк - говнокодеры, то контора бестолковая.

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

С таких ошибок правильнее было бы если б ФСТЭК ( или кто там занимается этим ?) запретило госзакупки уязвимых камней.

...и вернуть уже закупленные!

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

Кинцо можно смотреть без нажатия кнопки Х и ресурсов для этого нужно гораздо меньше

Что интересно, есть всякое кинцо, где пользователь только и может X жать. Выбирать варианты развития и все, а герои сами ходят. И вот такое кинцо и правда можно в виде кинца сделать - графон как за окном, а системные требования: калькулятор с цветным экраном. Но почему-то такое кинцо все равно крутят на 3D движках расходуя лишние ресурсы железяки

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

какие дыры? где появляются? и при чём тут локальные юзеры частных компов.

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

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

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

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

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

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

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

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

Анонсы пока (?) очень бумажные. Да и можно предположить, что от VIA там только патенты (и патентные соглашения), а что-то сделать пытаются китайские партнёры.

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