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)

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

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

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

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

Если в 64 разрядную вставят дополнительные тормоза, а в 32 разрядную не вставят...

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

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

32 разрядная ОС не даст прироста

Как это не дает? А потребление памяти, включая ненужность multilib? Для говнобуков с 1-2 Гб памяти на борту еще как дает, я проверял. Если на 64 битах фаерфокс (особенно на страницах с флешем) постоянно фризился при открытии >1 страницы, то на 32 при той же конфигурации работал ощутимо шустрее.

Man-o-Jar
()
Ответ на: комментарий от Man-o-Jar

Для говнобуков с 1-2 Гб памяти на борту еще как дает,

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

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

Теперь уже вопрос в штеудям, а что они это там делали 10 лет?
Как так можно было наговнякать исходники ЦПУ, что ой...всё?
И какой гений дралоскопил ARM64?

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

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

Ну мы как бы про общие случаи говорим
общие случаи

В общем случае железа с ≤4 ГБ памяти больше. Или ты предлагаешь в каждый офисный комп 32 гига пихать?

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

Хотя

Even with 'nopti' on the kernel commandline, you'd be paying the cost of switching between a second kernel stack on each syscall, etc

https://twitter.com/grsecurity/status/947260475305213953

За багу штеуда заплатят все.

Туда их http://s10.postimg.org/lsmz2iwll/How_to_code_with_no_bugs.jpg

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

надо программистов обучать на компах с памятью 1 гигабайт и процом 1 гигагерц

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

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

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

У меня ни одного андроид устройства не теряло заряд за час. Но видел такое на symbian s60, даже хуже, за пол часа аккумулятор в ноль уходил, а еще регулярные падения и перезагрузки, win5me тоже «радовал» падениями приложений и out-of-memory, и это в стоке, без сторонних приложений. Смешат разговоры про «раньше трава была зеленее». У меня жк телек работает 9 лет, не помню ни одного элт телика, чтоб проработал столько без вызова мастера. Сейчас все значительно надежнее работает.

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

Скорее всего имеется в виду не то, что прирост будет, а то, что падения не будет.

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

Пара мыслей.

1. Разрешение экрана современных телефонов чуть ли не опережает разрешение экрана стареньких мониторов 20-30 летней давности - то есть более число пикселей надо отрисовать - естественно, это более тяжёлая задача, вычислительных мощностей нужно больше.

2. С большим количеством вычислительных мощностей растёт и потребление энергии (хоть аккумуляторы и пытаются делать более ёмкими и маленькими, но менее долговечными), вот уже андройда и на сутки не хватает.

В общем, прогресс сам себя кусает за хвост - лично мне кажется, на 3-4 дюймах с более или менее приемлемым (не-HD) разрешением можно было и остановиться. Что мне толку от этого fullHD/superHD, если ресурсы расходуются, а глаз всё равно не замечает разницы?

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

Спорно

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

Бабий аргумент.

Не, бабий аргумент это был бы если бы я предложил тебе за это заплатить.

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

а глаз всё равно не замечает разницы

.>= 400 ppi твой глаз не видит?

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

У меня жк телек работает 9 лет, не помню ни одного элт телика

А у меня наоборот. ЭЛТ Самсунг до сих пор на даче работает. ЖК Самсунг (не из дешёвых, лет ~10 покупался FullHD) за ~5 лет «отработал» (гуглил, типовой дефект, но проще оказалось не чинить)...

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

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

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

h578b1bde ★☆
()

Я так понимаю, решено на фоне кризиса приподнять рынок десктопов.
-30% и жиреющие браузеры - теперь после апдейта в помойку отправится 90% ноутбуков и 70% десктопов старше трёх лет.

Yustas ★★★★
()

1) Патч будет в 4.15?

2) Когда ждать патч у RHEL на 3.10-х и 2.6.32-х?

3) Можно ли будет отключить данный «функционал», который будет снижать производительность?

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

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

Вестимо, не «Вы» «его», а наоборот.

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

Вестимо, не «Вы» «его», а наоборот.

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

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

Сейчас все значительно надежнее работает.

Ну да. «Запланированное устаревание? Не, не слышал.» У меня система до сих пор стоит на 80 Гб харде, IDE, конечно же. Остался со второго моего компа. Тем временем успел сменить уже два терабайтника от той же фирмы.

Man-o-Jar
()
Ответ на: комментарий от h578b1bde

Ещё раз. Я такого не заявлял, не выдумывай. Как и не призывал никого делать апгрейд старого железа, выкидывать его или что ещё ты там выдумаешь.

Я указывал на глупость комментария

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

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

1) Патч будет в 4.15?

Патч есть уже в 4.14.11, только что его собрал, oldconfig сказал, что появилась новая опция CONFIG_PAGE_TABLE_ISOLATION.

3) Можно ли будет отключить данный «функционал»

Можно собрать ядро с CONFIG_PAGE_TABLE_ISOLATION=n. Если ядро уже собрано с поддержкой PTI, то можно указать nopti в параметрах ядра при загрузке.

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

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

Я такого не заявлял, не выдумывай.

Если в 64 разрядную вставят дополнительные тормоза, а в 32 разрядную не вставят...

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

Склероз?

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

Патч есть уже в 4.14.11, только что его собрал, oldconfig сказал, что появилась новая опция CONFIG_PAGE_TABLE_ISOLATION.

Сделай нормальный тест, пожалуйста. Чтобы сравнить до и после. Ну хоть для бенча 7z b запусти.

praseodim ★★★★★
()

Надеюсь пользователей кукурзных AMD все эти исправления штеудо-проблемм не заденут?

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

Я указывал на глупость комментария

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

Не факт, 30% на 64 битах — вполне ощутимое падение производительности.

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

Что я могу сказать ещё

Правильно, иногда лучше жевать.

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

Выдумкой была твоя фраза:

32 разрядная ОС не даст прироста

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

Man-o-Jar
()

Решето, Сэр.

Теперь понятно, вынтель читерил чтоб работало быстрее! Я прозорливо не пользовался.

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

Ушел планировать теракт в штаб-квартире штеуда (на случай если тут есть представители фсб или анб, это шутка).

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

Не факт, 30% на 64 битах — вполне ощутимое падение производительности.

Если ты привидёшь примеры, что бенчмарки на 32 битах того же софта, что они тестировали, не будут отставать от 64 бит софта на это же или большее число, тогда - да. Но так нет такого...

fornlr ★★★★★
()
Ответ на: комментарий от Man-o-Jar

Ну да. «Запланированное устаревание? Не, не слышал.»

С 98 года у меня вышло из строя 0 дисков. Наверное я очень везучий. А еще я пользуюсь смартом lg p500 на android 2.2 с 2010 года, стоковый аккум до сих пор держит до 7 дней, а uptime до 200 дней.

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

, это шутка) За тобой уже выехали уточнить на счёт твоей шутки

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

Если ты привидёшь примеры, что бенчмарки на 32 битах того же софта, что они тестировали, не будут отставать от 64 бит софта на это же или большее число, тогда - да.

На железе с гигом памяти?

Не факт, 30% на 64 битах — вполне ощутимое падение производительности.

Но так нет такого...

Так ведь ведро с фиксом ещё не вышло.

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

Глаз отлично воспринимает разницу в отрисовке мелких деталей при dpi 96 и при 200+ (hint: шрифты, шрифты!)

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

Мне кажется ЛОР всё больше тупеет...

Как бэ и без твоего мамонтового железа сравнивали уже много чего.

И так и без этого патча, можно провести те же тесты на 32 и 64 битах и сравнить. А потом прикинуть ту просадку, о которой писали.

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

А теперь подумай, сколько в мире высоконагруженных серверов и сколько десктопов чисто для серфинга в интернете. Для полноты картины можешь вспомнить еще и об IoT.

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