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)

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

I would rather not just hard-code it in a way that we say one vendor has never and will never be affected

пишет Dave Hansen из Intel

Цитируй полностью, чтобы было ясно, о каком хардкоде идет речь:

«Does this disable it in a way that it can be turned back on via the kernel command-line?

This is a rather wide class of issues and I would rather not just hard-code it in a way that we say one vendor has never and will never be affected.»

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

эксплуатация в «сингуларити» намного сложнее

Что заставило тебя так подумать?

Намного сложнее если соблюдать техпроцесс сборки программ под данную ОС.

Я не об этом спрашивал. Какие свойства Singularity делают эксплуатацию уязвимости более трудной?

tailgunner ★★★★★
()

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

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

Мне на багу пофиг, больше производительность волнует. А вот админам и мажорам будет затратно.

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

Согласен, но на более быстром процессоре приятнее работать, особенно с тяжеловесным софтом.

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

Имеется в виду это:

заменить

/* Assume for now that ALL x86 CPUs are insecure */
setup_force_cpu_bug(X86_BUG_CPU_INSECURE);

на

if (c->x86_vendor != X86_VENDOR_AMD)
setup_force_cpu_bug(X86_BUG_CPU_INSECURE);

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

Если AMD не подвержены багу cpu_insecure ,
зачем их замедлять вслед за Штеудом? :(

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

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

Есто разница между «не смержен» и «разрабы из Intel мешают».

Если AMD не подвержены багу cpu_insecure, зачем их замедлять вслед за Штеудом? :(

nopti

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

с амазаном конечно можно пролететь

Говорят, Xen не подвержен.

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

да ладно, сейчас же никто не делает intel_cpu при загрузке на интеле или amd_cpu на амд.

ukr_unix_user ★★★★
()

Как я понял, и производительность сетевого стека будет тоже уменшина. С 30Gbps до 8-11Gbps, как в OpenBSD?

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

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

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

Ошибка проектирования всех процессоров Intel, выпущенных за последние 10 лет

У меня на даче для таких случаев есть Pentium 4 2003 года, надо только с него плесень стереть.
А при Сталине «Intel 8080» такого не было! :)

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

Кто, КТО эти уроды, которые постоянно ищут уязвимости в моем ДОРОГОМ Intel процессоре?! Им что, заняться больше нечем, руки некуда приложить?! Минус 30% производительности, а вернуть 30% стоимости моего компа они не хотят, нет?! Куда все катится...

Нет. Это рыночные отношения. Будь добр занести 20 труб за новый проц от АМД.

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

один из них публично не одобряет корректирующий патч а другие способствуют его игнору.
+ CEO Intel продал свои акции, ещё в ноябре причём

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

Пришло время откопать труп Singularity?

Что это, разработка от МС?

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

один из них публично не одобряет корректирующий патч

Если это утверждение сделано на основе приведенной тобой цитаты, оно неверно.

а другие способствуют его игнору.

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

+ CEO Intel продал свои акции, ещё в ноябре причём

А это вообще не имеет отношения к Linux.

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

Да, да, даже с учётом этого профита от 32 битной ОС не получишь

Мы говорим про глубокий энтерпрайз, где 64 Гб памяти это небольшой кеш, или про обычные домашние задачи, когда на глаз 32 бита от 64 не отличаются вообще никак, даже если в первом случае используется только 3,5 гектара из установленых 8?

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

Вообще рано паниковать. Выйдут исправления и потестим )

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

ну вот, а говорили, что третья мировая будет из-за нефти :)

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

Обычно их делают по остаточному принципу. Хорошо ещё если слабый APU засунут в дешёвую платформу от Celeron\Atom, так могут и засунуть самый мощный и минимальную дискретку рядом. Кажется ещё раньше видел что AMD хуже перегрев переносили, но не могу уже найти.

anonymous
()

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

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

А то вспоминается как угорали над эпплом, который замедляет старые девайсы.
А тут такое.

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

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

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

А так полностью согласен. 4 ядерные проц с 4 гигами оперативы еле тянет мобильный браузер.

Ramil ★★★★
()

Это начала работать программа замедления старых устройств. Как у эппл, только не у эппл. Скоро остальные крупные игроки подтянутся.

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

Какие свойства Singularity делают эксплуатацию уязвимости более трудной?

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

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

Но... Кругом в госах

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

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

в зене как раз всё предельно просто.

я давно говорю что все эти процессороделы, что штеуд, что амд, что армы и мипсы, скачут вокруг схемы томасулло. вот как её в 67м году придумали - так они ничего нового родить не могут. скотинко может(но я один и у меня нет мешка денег ,а то б уже) а они в принцие не могут. так вот, в ryzen они под вопли про «элементы исскусственного интеллекта» вхерачили в проц блок для «ускорения» бенчмарков. он как бы узнает код бенчмарков и впихивает «подсказки» чем заменить те или иные инструкции чтоб перло быстрее. но этот блок стал «узнавать» код gcc и всё начало падать.

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

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

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

Какие свойства Singularity делают эксплуатацию уязвимости более трудной?

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

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

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

Ну ты то придумал, да?) ты то нас спасёшь.

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

вообще там шина данных не влияет.

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

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

Зачем эти наркоманы ставят везде 4к и ультры? Они же CPU тестируют.

Мода такая. Ни чё не поделаешь...

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

а ты читал по ссылке текст?

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

мое предположение:

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

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

Вот я расчитал:

# Это новененький и самый дорогой проц от intel
> 80/100*30
24
> 80-24
56
# Это скорость виртуальной машины через tap без vhost и dpdk и без jumbo frame.
> 2/100*30
0,6
> 2-0,6
1,4
# Это скорость сетевых карт (Gbps)
> 1/100*30
0,3
> 1-0,3
0,7
# Это скорость сетевых карт (Mbps)
> 100/100*30
30

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

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

Для Электроника Д3-28 была ОС ВТ-МХТИ с прекрасным компилятором ЯВУ, вобравшим в себя элементы из фортрана, си и паскаля. Так что Вы тоже «слишком много кушать».

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

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

Да я понимаю. Шо такое ГД, кагбэ слегонца представляю =)

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

Или что там от неё осталось, я не знаю =)

По факту: есть СУБД. Вполне себе импортозамещённая. Скачивал демку специально, тыкал палочкой. Вполне адекватный продукт. На гиге достаточно отзывчив. Казалось бы, покупай и владей. Всем хорошо. Но нет, мы должны отвалить кучу бабла на буржуйский продукт, чтобы потом подсадить всю отрасль на иглу, параллельно громко болтая про проклятые санкции и «наш ответ Чемберлену».

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

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

wxw ★★★★★
()
Ответ на: комментарий от ne-vlezay

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

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