Comments 51
2% там, 3% здесь и вот — «Покупайте наши новые процессоры, они производительнее на 20% по сравнению с предыдущим поколением!».
Молодцы! Идут по стопам Apple. А что мне делать с моим ноутбуком на 6700k? Процессор без всего остального не поменять, сокет в 8700k другой, а в следующем поколении опять наверное изменят, да даже один только процессор не дешевый.
А есть где то сравнение скорости версий Windows 10 на одном и том же железе, типа 1803 vs 1703?
Говорят, этих уязвимостей не меньше семи — и три из них похлеще январских будуть… ;)
Производительность новых процов еле растет, так давайте старые затормозим. Хороший маркетинговый ход, с далека зашли.
Попробую намекнуть прямо — эти уязвимости относятся ко всем предыдущим поколениям, примерно за 10 лет…
Так вообще замечательно! Даже старенькое железо, исправно крутящее простенькие задачки, менять придется. Это же какие продажи внезапно попрут.
Но вообще конечно не особо приятные новости для различных сервисов. Цены немного подрастут, а кто-то и вовсе закроется. Остается лишь надеяться, что патчи будут раньше крупных утечек данных.
Но вообще конечно не особо приятные новости для различных сервисов. Цены немного подрастут, а кто-то и вовсе закроется. Остается лишь надеяться, что патчи будут раньше крупных утечек данных.
«Старые и новые» вы хотели сказать. Отличный маркетинг — покупайте наши уязвимые процессоры, других всё равно нет.
Скоро придётся им половину, если не больше, внутрипроцовых ускорителей исполнения убирать, ибо все они основываются на возможности сделать что-то заранее и имеют побочные эффекты на тайминги (ускорение же). И окажется что честно и без этих дыр можно работать на частоте не больше чем частота выборки из оперативной памяти (а это в лучшем случае сотни МГц). Ну ещё можно дать софту (или ОС) явную адресацию процессорного кеша как ещё одной области физической памяти, чтобы ОС, которая уже знает кого от кого надо защищать, сама клала в кеш нужные страницы по своему алгоритму. Это наверно будет медленнее чем сейчас (хотя в теории там можно сделать и более хороший алгоритм под конкретные нужды), но быстрее чем на частоте памяти.
Достаточно сбрасывать спекулятивно загруженную строку кеша.
Недостаточно, потому что загруженная строка вытеснит другую строку, и вытесненную нужно будет восстановить. Иначе можно будет определить, какая строка вытеснена.
Всё ещё хуже — неспекулятивный кеш тоже может что-то раскрыть про код, который его подгрузил. Хотя это эксплуатировать ещё сложнее чем то что имеется, но думаю найти подходящую ситуацию возможно. И закрыть это можно либо проверяя весь код на то, какие побочные эффекты на кеш он делает и насколько они вычислимы сторонним наблюдателем, либо переведя кеш на програмное управление.
Я предлагаю в стадию отката команды, когда обнаружена ошибка доступа, откатывать не только значения регистров, как сейчас происходит, но и состояния строк кеша. Для этого нужно завести пару-тройку «теневых» строк, которые будут подгружаться в спекулятивном выполнении, и коммититься в основной кеш, только если команда завершилась успешно.
Зачем убирать? Достаточно добавить корректные проверки доступа.
Там 10% потеряли, тут 8%. Это можно так допатчиться что пределом мечтаний станет запустить «сапера» или «косынку» на самом производительном процессоре.
Как бы на затычках не потеряли в скорости больше, чем даёт спекулятивное выполнение…
Да и вообще эти уязвимости кажутся мне настолько сложноюзабельными, а использование их настолько узконаправленным, что лучше бы было выпустить уже серию камней без "опасных" ускорителей для оборонки и параноиков, а в гражданском сегменте оставить всё как есть.
В гражданском сегменте есть банковские приложения, так что не следует считать, что безопасность не нужна.
Так на них левый софт не запускают же, а если кто-то и доберётся то ничего не поможет. Тут главная уязвимость — открыл страницу и яваскрипт тебя хакнул… вот это не приятно. С остальным можно бороться.
Приложения банков для удалённого доступа к банковским услугам, вообще-то, запускаются на устройствах пользователей. В том числе и через web.
Те же самые устройства часто одновременно используются и для других вещей.
Думаю, не нужно объяснять, что разделение адресных пространств процессов — отличная штука, и почему без неё будет, мягко говоря, неудобно.
Отключать обновления или покупать новый камень? Через годик выкатят новые уязвимости и закроют их 50% производительностью камня, вот тогда будет весело.
По-моему вполне логично, что чем сложнее система, тем больше в ней дыр.
И это касается и железа, и ОС, и прикладного ПО.
— У нас дыра в безопасности!
— Ну хоть что-то у нас в безопасности.
И это касается и железа, и ОС, и прикладного ПО.
— У нас дыра в безопасности!
— Ну хоть что-то у нас в безопасности.
Найдена новая уязвимость в процессорах
Однако, данная уязвимость была найдена в ноябре 2017 года, а Intel уже выкатила бета версии микрокода для OEM производителей чтобы те обновили свои продукты.
Апдейты пакетов с ядром собраны для RHEL и Ubuntu
Дело Ализара живет.
Такими темпами похоже что придется перейти на i7 просто потому-что с закрытием уязвимостей мощность серии упадет до уровня i5 (а сам i5 упадет до уровня кофемолки). Или вообще перейти на AMD.
В статье же пишут что AMD подвержены тоже.
Во времена когда трава была зеленее, где-то в 2012 году, удивлялся насколько 3770 быстр. Семерка загружалась за 10 секунд с hdd. Все остальное отрабатывало моментально.
И вот наступает 2018. Видео на Утубе переходит в полноэкранный режим за секунду (вместо сотен мс). Ощущение, как вы правильно описали, i5.
И вот наступает 2018. Видео на Утубе переходит в полноэкранный режим за секунду (вместо сотен мс). Ощущение, как вы правильно описали, i5.
А нет слухов, появятся ли вообще процессоры, в которых эти типы уязвимостей будут исправлены в железе?
Объясните кто-нибудь пожалуйста, почему возможность точного тайминга операций важна для непривилегированных процессов?
Инструкция чтения текущего такта давно доступна, и неизвестно, что сломается, если поменять её поведение (хотя, если отключить её только у браузера, наверное не будет проблем).
Но, если точный таймер убрать, время можно набирать или тупо статистикой, или выполняя операции в цикле и используя обычные часы.
Другой вариант — запустить 2 потока, второй поток тупо крутит i++ в цикле и таким образом обеспечивает приличную точность.
Но, если точный таймер убрать, время можно набирать или тупо статистикой, или выполняя операции в цикле и используя обычные часы.
Другой вариант — запустить 2 потока, второй поток тупо крутит i++ в цикле и таким образом обеспечивает приличную точность.
Запретить циклы, потоки и инкременты!
Запретили таймер и общий буфер между потоками: https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/
starting with 57:
- The resolution of performance.now() will be reduced to 20µs. (UPDATE: see the MDN documentation for performance.now for up-to-date precision information.)
- The SharedArrayBuffer feature is being disabled by default.
https://gruss.cc/files/fantastictimers.pdf Fantastic Timers and Where to Find Them: High-Resolution Microarchitectural Attacks in JavaScript (2017, doi:10.1007/978-3-319-70972-7_13) + https://gruss.cc/files/timers_slides.pdf
По-видимому, придется инженерам вводить новую сущность — свойство для нитей, которое отключает всю спекулярку и прочие потенциально опасные «ускорялки». Так сказать SecureThreadFlag. И для потенциально опасных приложений, типа браузера, это свойство устанавливать.
На мой взгляд, вся истерия со Spectre и Meltdown это перекладывание с больной головы на здоровую:
-процессор меняет очередность выполнения в угоду производительности;
-в процессе выполнения оказывается что что нарушено право доступа к памяти;
-процессор генерирует исключительную ситуацию: «тут процесс не туда полез, посмотри»;
-операционная система приложению: «тут процессор говорит что ты не туда полез, на посмотри где ты лажанул» (а раньше приложения регулярно крашились с ошибкой доступа).
Проблема не в том что процессор проверяет право доступа после операции доступа (да хоть 3-4 инструкции пропустит, за это время зловред практически ничего не успеет сделать с парой байтов секретной информации), проблема в том что операционная система в угоду «стабильности» передает не глядя обработку опасного исключения: «самому приложению».
Это как охранник пустит человека который ломится в закрытую дверь: «подождите я вам сейчас открою, тут закрыто», лишь потому что за 30 лет его к этому приучили люди которые постоянно забывают свои ключи или путают двери.
-процессор меняет очередность выполнения в угоду производительности;
-в процессе выполнения оказывается что что нарушено право доступа к памяти;
-процессор генерирует исключительную ситуацию: «тут процесс не туда полез, посмотри»;
-операционная система приложению: «тут процессор говорит что ты не туда полез, на посмотри где ты лажанул» (а раньше приложения регулярно крашились с ошибкой доступа).
Проблема не в том что процессор проверяет право доступа после операции доступа (да хоть 3-4 инструкции пропустит, за это время зловред практически ничего не успеет сделать с парой байтов секретной информации), проблема в том что операционная система в угоду «стабильности» передает не глядя обработку опасного исключения: «самому приложению».
Это как охранник пустит человека который ломится в закрытую дверь: «подождите я вам сейчас открою, тут закрыто», лишь потому что за 30 лет его к этому приучили люди которые постоянно забывают свои ключи или путают двери.
Хорошая защита от Meltdown — просто чистить кеши всех уровней при появлении исключения. Заодно говнокодеры, которые делают логику на exception-ах, задумаются.
Однако, от Spectre это не спасает. Когда процессор понимает, что он зашёл не в ту ветку из-за неверно предсказанного перехода, он откатывает регистры без уведомления ОС.
Однако, от Spectre это не спасает. Когда процессор понимает, что он зашёл не в ту ветку из-за неверно предсказанного перехода, он откатывает регистры без уведомления ОС.
Sign up to leave a comment.
Найдена новая уязвимость в процессорах