Группа исследователей из Калифорнийского университета в Риверсайде раскрыла (https://arxiv.org/pdf/1807.07940.pdf) сведения о новой уязвимости SpectreRSB, затрагивающей механизм спекулятивного выполнения инструкций в процессорах Intel. Уязвимость базируется на принципе восстановления данных, оставшихся в процессорном кэше в результате спекулятивного выполнения инструкций, ставших известными под именем Spectre (https://ssl.opennet.ru/opennews/art.shtml?num=47856) и позднее получивших развитие в атаках SpectrePrime (https://www.opennet.dev/opennews/art.shtml?num=48091), SgxPectre (https://www.opennet.dev/opennews/art.shtml?num=48173), BranchScope (https://www.opennet.dev/opennews/art.shtml?num=48344), Spectre 1.1, Spectre 1.2 (https://www.opennet.dev/opennews/art.shtml?num=48956), LazyFP (https://www.opennet.dev/opennews/art.shtml?num=48775), Spectre 3a и Spectre 4 (https://www.opennet.dev/opennews/art.shtml?num=48639).
В отличие от прошлых уязвимостей класса Spectre, новая проблема позволяет определять содержимое закрытых областей памяти через манипуляции с буфером возврата из стека (RSB, Return Stack Buffer), применяемым для предсказания вероятного адреса возврата. Несмотря на то, что подобные операции выполняются в ходе спекулятивного выполнения и отбрасываются, если предсказан неверный адрес возврата, результат предсказания остаётся в процессорном кэше и может быть восстановлен при помощи методов определения содержимого кэша по сторонним каналам, анализирующим изменение времени доступа к прокэшированным и не прокэшированным данным.
Атака сводится к следующим шагам:
- После переключения контекста на обработчик атакующего выполняется сброс содержимого общих областей (flush RSB) и засорение RSB данными с целевым адресом в адресном пространстве процесса жертвы;
- CPU переходит к выполнению процесса жертвы;
- При выполнении в процессе жертвы кода для возврата управления ("ret"), процессор считает, что находящийся в RSB адрес (занесённый атакующим) наиболее вероятно является искомым адресом возврата и спекулятивно обращается по нему, не дожидаясь подтверждения адреса возврата. После определения настоящего адреса спекулятивная операция отбрасывается, но результат обращения по заданным атакующим адресу оседает в кэше.Так как разные процессорные потоки используют общий буфер RSB, потенциально атака SpectreRSB может применяться не только для выявления значений закрытых областей в текущем процессе для обхода ограничений sandbox-изоляции, но и для организации утечки данных из других процессов и виртуальных машин, а также для обхода средств изоляции кода и данных, предоставляемых технологией Intel SGX (Software Guard Extensions). Наличие уязвимости продемонстировано в процессорах Intel. В частности, рабочие прототипы кода для атаки были протестированы на системах с CPU Intel Haswell и Skylake, а также для определения содержимого анклавов SGX2 на системах с Core i7 Skylake. Процессоры AMD и ARM не проверялись, но, судя по наличию в них поддержки RSB, вероятно они также подвержены уязвимости.
По сведению исследователей, для блокирования SpectreRSB потребуется применение нового метода защиты, так как ни один метод, реализованный для защиты от прошлых атак Spectre, включая Retpoline, не эффективен для блокировки SpectreRSB. Компания Intel не согласилась с таким мнением и заявила, что для блокирования SpectreRSB можно использовать уже существующие типовые методы (https://software.intel.com/sites/default/files/managed/c5/63...) защиты от атаки Spectre. Для защиты от утечки данных из областей памяти ядра и при переключении контекста между разными виртуальными машинами предложена техника защиты "RSB refilling", которая уже включена (http://undeadly.org/cgi?action=article;sid=20180724072257) в состав OpenBSD.
Тем временем, компания Rad Hat опубликовала (https://access.redhat.com/blogs/766093/posts/3510331) утилиту (tar-архив (https://people.redhat.com/~nickc/Spectre_Scanner/)) для анализа исполняемых файлов, библиотек и сборок ядра Linux на предмет наличия последовательностей инструкций, допускающих проведение атаки Spectre v1. Утилита пока поддерживает только анализ кода для архитектур x86_64 и AArch64.
URL: https://www.theregister.co.uk/2018/07/23/spectre_return_stac.../
Новость: https://www.opennet.dev/opennews/art.shtml?num=49015
> Представлена SpectreRSB, новая уязвимостьПисали бы сразу - "разработана новая уязвимость".
рассекречена
Шо, опять?
Да http://www.hobobo.ru/diafilmy/diafilm-gorshok-kashi/
Говорили же, что долго спектра будет преследовать.
Да инструкций, которые тем или иным способом условно читают память в проце до ... (ну очень много). И почти каждую можно заставить делать это понарошку. Вот каждый кто и старается вписать свое имя в историю. Пока все не застолбили.P.S. Сдается мне скоро только NOP не будет использоваться для Спектра. Но если что - я был первым. :)
Не соответствует действительности.
Современные CPU поддерживают считанные сотни инструкций.
В случае risc решений, работа с памятью вовсе сводится загрузке новых инструкций, pref, load/store и ll/sc. что никак не подпадает под очень много.
ну вот и будут у нас "считанные сотни" подобных уязвимостей.
Каждая со своим кривым и тормозным методом частичного и неэффективного обхода.а про ваши риск-решения забудьте, мертвы те риски десять лет уже как.
а я вот жду не дождусь пока эти спектры до мипсов доберутся, похоже пока их там еще никто не искал, а стоят они чуть не в каждом домашнем рутере. Если что, мы тоже такие девайсы разрабатываем - клиенты уже спрашивали, начальство пока смело отвечает что "уязвимостей не выявлено".
Если что, мы тоже такие девайсы разрабатываем - и какое там ядро?
пока эти спектры до мипсов доберутся, похоже пока их там еще никто не искал - какие-то варианты уязвимостей точно есть и в mips.в роутерах/камерах и.т.д. скорее всего сейчас многопточный in-order без спекулятивного исполнения.
*увы, хорошо знаком только с относительно старыми решениями.
https://wikidevi.com/wiki/MIPS_24K . И я как раз о том что какие-то похожие проблемы там вполне могут быть, и будет забавно когда они там всплывут.
arm или mips мертв? riscv мертв?
в том же телефоне притаился arm.
в том же роутере притаился arm, mips или powerpc.
последние годы я не писал кода для x86/amd64.
Почему мертвы, живее всех живых. Просто в тех из них у кого есть внеочередное выполнение команд уязвимы, то есть например все 64битные arm
> то есть например все 64битные armНет, далеко не все. Помимо того, что не все из 64-битных ядер поддерживают внеочередное исполнение, в новом ядре Cortex-A76 большинство дыр уже закрыто.
А я тебе верю. Я вообще - всем верю! (С) :-)
забавно, но даже NOP тайминг зависит от состояния процессора, как минимум для arm не гарантровано будет ли на неё затрачен цикл или нет, она могла попасть в конвеер с другой инструкцией. Так что возможно и из NOP можно извлечь что-то интересное
2018-год (как и предстказывали в начале января) -- это год позора процессорных корпораций..придумать предсказатель ветвлений смогли -- а сделать нормальный кэш (работающий *тесно*-интегрированно с системой предсказания) не смогли.
такая очевидная недоработка что просто ппц. о чём они вообще думали.
> о чём они вообще думали.о том, что такого рода уязвимости - чисто теоретические конструкты, не реализуемые в реальных условиях
Они вполне конкретно реализуемые. Просто под каждый вариант проца нужна своя конкретика.
ну собственно вот в этом нас и убеждает текущий год, я не спорю
Как я понимаю, пока их конкретно реализуют в виде работающих образцов, которые из одного своего потока неправомерно узнают данные другого. Для получение чего-то действительно ценного в реальных условиях требуется "немного" другая реализация, причем эту реализацию еще нужно будет пропихнуть на компьютер жертвы.
Скажем, крутится внутри локалки сервер баз данных. В списке угроз, от которых его требуется защищать, эти уязвимости процессора будут не раньше второй страницы... примерно в районе сейсмической опасности на Среднерусской равнине.
> причем эту реализацию еще нужно будет пропихнуть на компьютер жертвыэто нынче просто... браузеры, миллионы cdn'ов, общая привычка уже не обращать внимания на слежку одновременно гуглем-яндексом-и-еще-хер-знает-кем, obfuscated js, asm.js, webassemly...
причем юзер уже и к тормозам тоже привык, он вон майнинга не замечает - поэтому и попыток анализа кэша... ну не то что не заметит, а "блин, опять все тормозит... перезагрузиться что-ли, или до завтра так как-нибудь"
И много вы наанализируете процессом, запущенным хрен знает каким браузером в хрен знает какой песочнице? А главное - что вы такого ценного ожидаете выловить на юзерском компьютере, чтобы так заморачиваться? Дeбилов-то доить - и шифровальщики сгодятся... без всяких нанотехнологий и предсказаний остатков в кэше.
>А главное - что вы такого ценного ожидаете выловить на юзерском компьютереКлючи, пароли, явки. Номера счетов, сертификаты, PIN-ы и пр.
>Дeбилов-то доить
Ну тут - да! С тебя доить нечего!
Но вот если CFO какой нить компашки подловить ...
У братьев славян (да и у не-братьев славян - тоже! :-) - дык вообще заведено что дир входит во все админские группы и имеет ключи\сертификаты для всего. И попробуй ему запретить софт "нужный" ставить и на сайтеги "про это" ходить :-)
Вот этих в первую волну схарчат :)
> Ключи, пароли, явки. Номера счетов, сертификаты, PIN-ы и пр.Для этого даже после успешного запуска эксплойта на компьютере жертвы потребуются усилия, сравнимые со взломом сервера. Чтобы тупой робот мог вытащить из вашего (заранее неизвестного) браузера что-то ценное через игольное ушко этой уязвимости... пока не услышу о том, чтобы кто-то с этим реально справился - не поверю.
> он вон майнинга не замечаетУ меня сразу горячий корпус станет если кто-то начнёт активно видеокарту юзать, так что слишком уж заметно.
скажем работает в сети сервер виртуального хостинга или сервер с виртуальными машинами и выполняет куча разного в том числе и вредоносного кода.
А тут его еще и взломали через внеочередное выполнение команд.
о чём они вообще думали - о продажах думали.
думали, как побыстрее выкатить решение, которое вполне себе можно продавать.
выкатили. продается.
https://www.amd.com/ru/ryzen-pro
> такая очевидная недоработка что просто ппц.А вообще, хочу заметить - легко говорить "такая очевидная". Процессор - сложнейшая система, всё-таки, и в Intel не дураки сидят - просто всё предусмотреть невозможно в условиях такой сложности. Нам с вами в общем-то легко говорить, но попробуйте сами разработать процессор без дырки
Им про это говорили, AFAIK, еще много лет назад. Те отнекивались, мол, всё хорошо, всё под контролем. Ну и многие верили на слово, ведь не дураки сидят.Доверились.
Ну, кстати, в ARMах вроде как тоже нашли подобные уязвимости, и в большинстве архитектур со спекулятивным выполнением. Понять это можно, на самом деле - пока эти уязвимости считались абстрактной теорией, вносить удорожающие и замедляющие поправки в сложнейшие системы, где каждый микрометр кристалла на счету - неразумно и невыгодно
Для нормального процессорного инженера всё не так уж сложно. Они же не х86 с нуля каждую неделю в одиночку делают.
> позораОни за это деньги от АНБ\ФСБ и прочих Отделов К получили. Чихать им позор это или нет.
Ага, на акции чихать, которые дешевеют, на бабло чихать, которое тает
вот только акции Intel за последний год стабильно идут вверх, а не вниз.
Ну дык правильно! Если на твоих серверах есть что то ценное - ты купишь новые камни. Которые, как известно - "без дыр, мамой клянусь!" (С)
> о чём они вообще думали.О том, что те, кто печётся о безопасности больше чем о скорости и фичах, на рынке не задерживаются.
нравится мне позиция анонимов Opennet'а. Каждый горазд обозвать нехорошим словом проектировщиков как минимум Intel. А ничего, что это сложнейшее дело? Легко сказать теперь,что вот такие они недоучки, не подумали о том-то и том-то. Такое впечатление, что в комментариях одни только проектировщики процов сидят.
>>Каждый горазд обозвать нехорошим словом проектировщиков как минимум Intel.На базаре вам продали гнилую картошку, каким "добрым словом" вы обзовете продавца?
Продали не гнилую, а супер пупер новую и навороченную. А то что из нее броня не очень, так это к производителям картошки отношения не имеет, скорее к тем кто ее для этого использует. :)
Можно было и предусмотреть, что из картошки будут делать броню. Это долг производителя обществу. Либо ты предусматриваешь все, либо платишь по суду. А суды будут как только появятся интервью с агрономами о том, что они заранее знали о невозможности изготовления брони из картофеля, но нагло замалчивали сей факт, получая прибыль с дефектного продукта.
вы привели пример нецелевого использования, а я описал в общем куплю-продажу готового продукта (гнилого), это немного разные примеры.пс: "микроскопом гвозди забиваю" :)
Ваш пример не подходит к этой ситуации. Картошка - предмет относительно простой, да и гниль вполне легко можно определить. Процессор же - сложнейшая система, в которой невероятно трудно охватить все возможности и последствия. Если бы проектирование процессоров было бы таким же лёгким, как выращивание картошки, ваш пример был бы обоснован. Однако нет - каждый новый процессор мало того что сложен сам по себе, так ещё надо разрабатывать надо - сложней процесс.
ппц, и куда делся мой комент?
> ппц, и куда делся мой комент?сюда: https://www.opennet.dev/cgi-bin/openforum/vsluhboard.cgi?az=l... . Действительно ппц. Анальная автомодерастия.
))) спс, не знал про "жуков" запретных
>нравится мне позиция анонимов Opennet'а. Каждый горазд обозвать нехорошим словом проектировщиков как минимум Intel. А ничего, что это сложнейшее дело? Легко сказать теперь,что вот такие они недоучки, не подумали о том-то и том-то. Такое впечатление, что в комментариях одни только проектировщики процов сидят.Отличный настрой, прямо ностальгией повеяло.
они какбэ не за спасибо их делают. да и все возможные палки юзерам вставляют ( меняют сокеты как перчатки)
так что еще мало тут их критикуют:)
я не говорю, что Intel как компания - ангелы. Но конкретно проектировщиков процессоров трогать не стоит. Они занимаются сложнейшим делом. То, что Intel стрижет деньги заменой сокетов - это уже не к ним претензии, а к руководству Intel.
Не-не-не, Дэвид Блейд, так не пойдет. Интел это вся компании, продающая мне продукт, который результат работы всех сотрудников. Я ж не к конкретному Бхавину претензии предъявляю, а ко всей корпорации и не важно что Аллочка из бухгалтерии сущий ангел, а подлости творит ее начальник. Кто конкретно там ложка дегтя меня в принципе интересовать не должно.
Обычно такие теоретико-идеалистические мировоззрения разбиваются о правду суровой реальности.
корпорацию можно много за что покритиковать, иное дело что тут оскорбления именно против инженеров компании
>А ничего, что это сложнейшее дело?для анонима опеннета не существует сложных дел! (по причине ограниченности кругозора этих анонимов, хотя сами анонимы верят, что по причине собственной нереальной крутости)
> Каждый горазд обозвать нехорошим словом проектировщиков как минимум IntelПо головке гладить предлагаете? Спасибо, Intel, за Js-эксплоиты!!
Предлагаю не поливать грязью проектировщиков устройств, которые занимаются сложнейшим делом. У самой корпорации рыльце-то в пушку, конечно
Либо они не знали что делали, и оказались недостаточно профессиональны, либо знали, и тогда это уже умышленное нанесение ущерба потребителям посредством замалчивания информации о существенных дефектах. Ничего личного.
Говорю же, это дело настолько сложное, что ни один человек не может всё предусмотреть.
а зачем же спрашивается всё так усложнять, что чёрт голову сломит?
Потому что хочется выжить в конкурентной борьбе. И не просто выжить, а и заработать. Следовательно - выжать всё, что можно, с разумными рисками - теми, которые видели. Ваш К.О.
и кто же Intel-у конкурент? :)
Ну вот раз конкурентов заморили - значит, стратегия правильная
"конкурентов нет" не значит, что не должно быть "книги жалоб", в пекло такое "заведение"!
Какая книга жалоб? Речь была о "зачем же спрашивается всё так усложнять, что чёрт голову сломит? " - ну вот затем, что это позволило сделать продукт, который хотел рынок. Что и наблюдаем на практике в виде интеловской доли рынка.
>>Какая книга жалоб?как это какая? - с них строгий спрос должен быть, от их гавноподелок спекулятивных порой жизнь человека зависит.
AMD, ARM
Intel держит груз обратной совместимости. А так-то да - такая сложность совершенно неоправданна. Но вообще удивительно, что инженеры Intel умудряются и на такой пропитанной костылями архитектуре делать высокопроизводительные компьютеры
> Говорю же, это дело настолько сложное, что ни один человек не может
> всё предусмотреть.Внимание инженеров Intel на наличие подводных камней обращали.
И, да, если, например, ваш ребёнок помрёт из-за неверно поставленного диагноза, у вас тоже к врачу не будет вопросов?
Вопросы могут быть, но их причина - эмоции. А рационально говоря - оцениваем, сколько у данного врача неправильно поставленных диагнозов, и если не хуже, чем средний уровень - то какие претензии - на божественное совершенство никто не претендует.Так и здесь - учитывая, что прилетело всем основным игрокам - плюнуть, растереть и сказать - этап такой развития технологий.
2+2 "не равно" 4, математики допустили ошибку, эмоции меня толкают на то, чтобы я сжёг до тла Ынтел, Бог ошибся и создал "идиотов"!пс: ваша честь, вопросов больше нет.
Объясняю по буквам. Совершенных, никогда не ошибающихся гениев нет - ну вот не завезли как-то. Инженеры могут допустить ошибку в проектировании. И будут допускать, вопрос - с какой частотой, как это выловить и так далее. И периодически выловить не выйдет, потому что тестировщики тоже не идеальны, и условия тоже не идеальны. Ошибки будут попадать в паблик, процедуры разработки и тестирования - корректироваться и так далее. Не бывает по-другому.И докторов совершенных тоже не видать. Всегда будут ошибочные диагнозы, (несовершенные) процедуры, призванные уберечь от фатальных последствий и т.д. Мать погибшего ребёнка это, понятно, не утешит, но это неизбежно.
>>Инженеры могут допустить ошибку в проектированииВы понимаете, что значить допускать ошибку в проектировании?
>>Всегда будут ошибочные диагнозы
Ошибочный диагноз - халатность!!!
Как я уже говорил в нити выше, уязвимость считалась теоретической (и если честно, пока что она тоже только в синтетических условиях воспроизводится). Плюс уязвимость есть и у продвинутых ARMов, насколько я знаю. Да и у АМД вполне может быть, если у них какие-то варианты не работают, то это не факт что все. Но АМД, конечно, использовало это как пиар-ход, что логично
Вообще-то AMD Spectre признавало, это Meltdown у них нет.
Ну окей, спутал. Просто помню, что какая-то часть AMD не затронула, но только лишь часть
Там вроде два варианта спектра было. И на одном из них по моему нельзя получить желанного результата, а вот второй признали. Хотя это не точно, но по моему так было.
Да как бы не обязательно, то что нынешние процессоры содержат кучу обвеса по ускорению производительности не означает что весь этот обвес они получили сразу же.
Из истории - кэш впервые появился в 80386, а спекулятивное выполнение команд в 80486 (если мы рассматриваем продукцию Intel, и я не ничего не напутал, данные брал с википедии). Это не означает что разработка спекулятивного выполнения команд началась сразу после внедрения кэша. Это могли быть параллельные проекты, т.е. одна команда разрабатывает кэш, другая систему предсказаний (и выполняют тысты зная только о своих новшествах - тесты проходят на ура, проблем нет если есть одна и нет другой). В некоторый момент команде которая работает над спекулятивным выполнением команд преподносится факт о том что у процессора теперь есть кэш. А времени проверить какие из этого могут быть последствия уже нет, т.к. процессор, для которого они разрабатывали свою фичу уже нужно пускать в производство. А в дальнейшем все забили на проблемы с безопасностью, т.к. те кто их может и увидел посчитали что они только в теории возможны (и довольно хорошо посчитали, раз обнаружили их только сейчас).
Никто не спорит что дело сложное, но раз сложное то и процы каждый год может и не стоит выпускать? Им то безразлично своруют ваши данные или нет - им прибыль подавай.
Это вопрос уже к менеджементу и самой корпорации Интел, а не к инженерам.
> А ничего, что это сложнейшее дело? Легко сказать теперь,что вот такие они недоучки, не подумали о том-то и том-то. Такое впечатление, что в комментариях одни только проектировщики процов сидятво первых: уязвимость просто очевидная -- спекулятивная ветка отработав по НЕВЕРНО-предскзанному пути НЕ подчистила за собой ВСЕ побочные эффекты. хотя поопределению это ДОЛЖНА была сделать. это просто протеворечит самой сути идеи предсказателя ветвлений! неувидить (якобы не увидить) этого -- это просто халатность в полной мере.
во вторых: разработка процессоров Intel (и других уязвимых спектром проессоров) происходит за закрытыми дверями -- НЕ давая анонимусам увидить и подсказать.
в третьих: популярные открытые реализации процессоров оказались НЕ подвержены спектру -- так как их разработчикам хватило ума НЕ обращаться к кэшу в момент спекулятивной ветки.
в четвёртых: у Intel УЖЕ довольно сложная реализация кеша, поддерживающие всякие хитрые вещи, например защита от его вымывания активностью низкоприоритетного процесса. можно сделать вывод что *тесная* интеграция кэша с системой спекулятивных вычислений -- вполне была по силам Intel-проектировщикам.
> уязвимость просто очевиднаяЭто нам сейчас она просто очевидная. И потом, я в нити выше уже говорил - она считалась абсолютно теоретической и нереализуемой. Если честно, она и сейчас в основном только в синтетических тестах реализуется
А нельзя этот кеш вообще отключить? И так понятно, что от него одни беды и все уязвимости все-равно не вычистят
помню я отключал L1 и L2 кеши у P3-500 чтобы поиграть в древние игры. прои-ть без кешей была как у 286 :)
так что если у современного проца отключить все кеши (если это вообще возможно), то про-ть будет на уровне 486 или младших пентиумов в лучшем случае.
> помню я отключал L1 и L2 кеши у P3-500 чтобы поиграть в
> древние игры. прои-ть без кешей была как у 286 :)Я ничего не понял.
0 а зачем их отключать вообще? Неужели древние игры с кешами не идут?
1 это вообще возможно?
не идут
отключается из биосзы как там каникулы проходят?
Отключение кеша приведет к катастрофическому падению производительности на несколько порядков.
> Отключение кеша приведет к катастрофическому падению производительности на несколько порядков.а если его отключить ТОЛЬКО для спекулятивной ветки -- на сколько порядкой?
точнее даже говоря не вообще отключить для спекулятивной ветки -- а не позволять его менять внутри спекулятивной ветки (но позволять читать из него)
тогда команды, которые выполняются в рамках спекулятивной ветви будут на несколько порядков дольше выполняться (если это работа с памятью) - толку от такого прироста производительности.
тогда уже логичнее отключить спекулятивное выполнение команд, вместо кэша, это даст просадку раза в 1,5 - 5,0, но не на порядки как при отключении кэша.
> тогда уже логичнее отключить спекулятивное выполнение командотключение спекулятивного выполнения команд -- уже подразумевает внутри себя отключение функции изменения кэша внутри спекулятивной ветки.
а ведь неисправность именно в том что спекулятивная ветка не способна откатить-назад состояние кэша. но сам по себе кэш (без спекуляции) и спекуляция (но без кэша) -- работают корректно :-) ..
если мы НЕ будем отключать полностью спекулятивность, оставим возможность спекулятивной ветки, запрещающую изменять кэш, но с возможностью читать из кэша. то в этом случае спекулятивная ветка будет хорошо нам помагать с различного рода математическими вычислениями и узкими циклами. то есть алгоритмы которые работают интенсивно с данными умещающими-ся в кэш полностью. спекулятивная ветка станет короткой -- но даже так это лучше чем ни какая.
>сам по себе кэш (без спекуляции) и спекуляция (но без кэша) -- работают корректно :-)Не совсем. Некорректно работает именно кеш. Ибо он не проверяет права доступа в соответствии с контекстом исполняемой инструкции. Типа что в кеш попало - стало общим достоянием.
Спекулятивное исполнение добавляют жару ибо позволяют загрузить в кеш то что требуется в обход проверок (или считать до сброса при переключении контекста).
Полноценно же проверять контекст при работе с кешем - будет гораздо медленнее, там и так времени на полноценный разбор адреса то нет.
>а если его отключить ТОЛЬКО для спекулятивной веткиВесь смысл спекуляции - заранее подгрузить память в кеш.
Если процессор будет спотыкаться об каждый операнд и ждать по 200 циклов пока подгрузится та память в которой ссылка (+еще ждем) на другую память, а потом еще и ту страничку в которой ссылка на второй операнд, а потом еще и то место куда надо записать результат. Производительность просядет ого-го как. Поэтому и придумали механизм при котором в кеше данные подгружаются заранее, не до конца вычислив все ссылки. ,Поначалу казалось, что единственный вред - кеш будет замусореваться. Ан вон оно чё Михалыч... :)
Да сколько можно? Хватит прошу Вас!!!!
Ага! Припекло!!!
Таки на эльбрусы пора переползать?
https://monster6502.com , паяльник в руки и алга
нет спасибо, мне и с fpga хорошо
о, предлагаю тему для диссертации: "исследование потенциальных уязвимостей спекулятивного выполнения инструкций в soft-core процессорах"
с soft-core проще - его можно обновить уже после выпуска, но только стоять такие "процессоры" будут дороже золота.
И производительность будет ни к чёрту
вообще современные fpga нифига не свободные, это наркотик следующего уровня, за большие деньги создает иллюзию полёта, потому что производители совсем не раскрывают что у них внутри, и протоколы программирования насколько могут не раскрывают. Жесточайшая проприетарщина, которая как-бы позволяет разрабатывать свободное железо.
Так-то некоторые процессоры в прямом смысле дороже золота стоят
tsmc умеет 7нм, в отличие от этого вашего дырявого штеуда
>Представлена SpectreRSB, новая уязвимостьЗвучит, как будто фичу зарелизили :)
это Россия подрывает рынок ЦПУ, чтобы перекинуть всех на Эльбрусы. помяните моё слово: такие отаки будут появляться до тех пор, пока Интел с АМД не перейдут на производство FPGA - систем, доступных для масс и востревоанных ими.
это Россия подрывает рынок ЦПУ, чтобы перекинуть всех на К155
KT315-х сотни вагонов, девать некуда, если разогнать выше гигагерца там уже кубический рост пропускной способности в совокупности с квантовыми эффектами. резерв секретных технологий
Скорее уж на АРМ/свободную архитектуру и китайцев. Дешевле и проще, мб и по закладкам почище.
ARM вообще-то тоже уязвим, как и _любой_ _современный_ процессор с внеочередным исполнением, т.к. это уязвимость именно в концепции, а не конкретной архитектуре
Не ну а чо, все логично: вот вам последствия монопилии (ладно, двух) на рынке ЦП. Свет клином не сошелся на интелях с амд, и не про убожеский arm речь, но.. геймеры, всякая "высокопроизводительная" хренота, погоня за нанометрами - и в итоге все в жопе))
> Не ну а чо, все логично: вот вам последствия монопилии (ладно, двух)
> на рынке ЦП. Свет клином не сошелся на интелях с амд,
> и не про убожеский arm речь, но.. геймеры, всякая "высокопроизводительная" хренота,
> погоня за нанометрами - и в итоге все в жопе))В порядке просвещения: «две монополии» (а также три и так далее, пока число участников остаётся малым и легко возможен картельный сговор) — называются «олигополия».
Да как не называй.. а про нанометры еще смешнее, например вопрос радиационной устойчивости ЦП типа не стоит вообще. Ну Ок, предсказываю еще кучу "новостей", как перейдут на 7нм)))
Ну вот когда встанет вопрос - тогда и будут решать. На всё заранее закладываться - вообще ничего не сделаешь.
Тогда уже нихрена не решат)) Как и сейчас - со всеми Spectre*> На всё заранее закладываться - вообще ничего не сделаешь
Не, ты не понял главного - меньше бобла "вот прямо сейчас".
Меньше бобла "вот прямо сейчас" - оно достанется кому-то другому, кто не постеснялся, только и всего. Результат будет тот же, просто лейбочка у лидера другая. Потому что это не благими намерениями управляется, а потребностями рынка.А сейчас как раз со Spectre понятно - где критична безопасность прикроют патчами, где критично быстродействие - внешними защитами, где ни черта не критично, как 99% пользовательских машин - будет тяп-ляп. За пару-тройку лет сменится основной парк, да и всё. Ну да, было бы менее болезненно, если бы нашли пораньше ("нашли" = "продемонстрировали на практике"). Но в общем и целом совершенно нормальный процесс. Если делать продукты со сложностью, находящейся на пределе достижимого (а рынок требует, иначе - см. выше), то фейлы гарантированы, непонятно только, когда и как прилетит.
> Не ну а чо, все логично: вот вам последствия монопилии (ладно, двух) на рынке ЦП.А что вам не нравится? Нам вот все нравится - у них монополия, их и хакают. А наш power с точно такими же проблемами и из того же источника - ну один раз пощупали, слегка, даже работающего PoC не выкатили, а потом и вовсе забыли.
Эээ! Горшочек, не вари!
Напрашивается лишь один вопрос: чем занимались эти исследователи все эти годы, что начали плодить обнаружения уязвимостей после появления Spectre/Meltdown. Все эти годы подавались дырявые процы и всем было по фигу, но сейчас все трубят в трубы во все лёгкие.
Просто до недавнего времени просто никто не додумывался до того, что когда что-то достаётся быстрее обычного (т.е. из кэша), это уже небольшой сайдэффект. Казалось бы, и ладно, но эти самые кэши общие между процессами, а это уже позволяет одному понять, что происходит в памяти у другого. В случае с этой конктретной SpectreRSB люди ещё вспомнили, что RSB тоже один на всех и все за одного^W^W^W^W. Что примечательно, в ядре патч фактически от него приняли ещё в середине января, то ли автор патча знал заранее, то ли сам догадался (что немудрено, учитывая, что этот spectreRSB - один-в-один spectre v2, только вместо обучения бранчпредиктора адрес гаджета заносится в RSB).
Милиционер в ночи подходит к пьяному мужичку, который что-то там ищет под фонарём. Говорит "здраствуйте, что происходит?". Тот отвечает, мол, ключи ищу.
- А где вы их потеряли?
- В парке.
- А чего тогда здесь ищите?
- Тут светло.Это древний бородатый анекдот, в котором отражён принцип любой поисковой/исследовательской деятельности. Сначала человек ищет там, где удобно искать, и лишь потом во всех остальных местах.
Как я понимаю всю эту историю, ей предшествовали атаки на реализации криптографических алгоритмов, которые замеряли тайминги или изменение шума кулера по времени. Когда технологии извлечения информации из этих замеров были отработаны на криптографии, а все здравомыслящие разработчики криптографических алгоритмов научились реализовывать их так, чтобы время выполнения, потребляемая мощность и все остальные измеримые характеристики не коррелировали бы с тем, насколько правильные используются ключи, исследователям стало нечего делать. Но технологии-то выполнения замеров и извлечения из них информации уже есть... А раз есть, то надо куда-то их применить... И вот тут выяснилось, что процессоры внутри тоже содержат алгоритмы и время выполнения этих алгоритмов меняется в зависимости от секрета.
Некоторое время технологии допиливали, генеря новые идеи которых недоставало для того, чтобы просто взять и написать эксплоит. Сейчас их довели до ума, и чем больше опубликовано уязвимостей, тем проще любому мимопроходилу понять принципы, стоящие за этими уязвимостями, и изобрести способы поиска новых.
Но дело не только в этом. Знание того, что нечто возможно очень помогает этого достичь. Когда есть сомнения в возможности реализации идеи, реализовать её гораздо труднее. Майкл Абраш в своей The Black Book[1] рассказывал историй о том, как это работает. Как знание того, что возможно создать реализацию алгоритма которая будет работать в два раза быстрее, помогало ему создать эту реализацию.
А последнее, что я отмечу, есть такая штука, как hindsight bias[2], в результате которого любая проблема выглядит гораздо проще после того как она была решена, чем до того. Проблема может выглядеть неразрешимой априорно, и элементарной, когда есть решение. Поэтому если тебе кажется, что результат исследовательской деятельности не соответствует времени и усилиям, затраченным на исследование, то с большой вероятностью ты наблюдаешь hindsight bias. Во-всяком случае это именно так, когда альтернативные объяснения сводятся либо к глупости исследователей, либо к теории заговора.
[1] https://github.com/jagregory/abrash-black-book
[2] https://en.wikipedia.org/wiki/Hindsight_Bias
Как чем занимались? Уязвимости искали, но в софте. Искали и находили, и исправляли.
Каждый месяц по уязвимости, до тех пор пока внеочередное выполнение команд не отключат совсем.
> Каждый месяц по уязвимости, до тех пор пока внеочередное выполнение команд не
> отключат совсем.Звучит как угроза террористов, взявших заложников. :(
А вот интересно - есть вообще в принципе конкретные случаи реального ущерба от этих уязвимостей? И под этим я подразумеваю не издержки из-за тормозов от патчей и не траты на лечений пошатнувшейся на почве паранои психики, а случай когда HaKZoR1337 исключительно благодаря этим конкретным уязвимостям (без них бы не смог) украл у пользователя vasian123 его драгоценные миллионы или оче секретную информацию. А то воплей на весь мир, конец света обещают, проблема 2000, все дела, а пострадавших что-то не видать. Затянувшийся хоровод вокруг солонки какой-то. Ну или спланированная PR-акция, кому как больше нравится понимать.
Сколько я понимаю, пока что эти уязвимости воспроизводятся только в синтетических условиях. В реальных условиях это нафиг никому не надо, легче через дырку в ОС, сервере или CMS какой-нибудь пролезть. Ну или пароль admin
> есть вообще в принципе конкретные случаи реального ущерба от этих уязвимостей?Вспомни историю про хакера и солонку. Вот spectre это оно и есть.
Эксплуатация следов не оставляет в случае, если весь код не залоггирован.
Дай ссылку на эксплоит, запускающий gedit (браузер etc) на хосте, будучи запущенным в VB.
Или признайся в п*больстве.
> А вот интересно - есть вообще в принципе конкретные случаи реального ущерба от этих уязвимостей?а я тебе открыточку должен выслать - "бабки с твоего инет-банка сняты благодаря уязвимости, баллоны кати на интел, я не виноват"?
в том и проблема, родной, что твои данные уплывают тихо и незаметно, без всяких .pwned в хомяке.
да никому это не надо потихоньку, легче ломануть ОС и сразу стащить всё. Или пароль подобрать.
Кто-то подсчитывал, сколько производительности в итоге сожрали все спектры плюс мельдоний? Не удивлюсь, если суммарно просядет вдвое.
Около 30% в сумме в самом худшем случае. И лишь сугубо в серверных нагрузках...
> И лишь сугубо в серверных нагрузках...Гонево. У меня на ноуте в браузерных Javascript бенчмарках(Kraken и Octane) при включении защит попугаи уменьшаются на ~15-17%.
лайфхак: нужен новый костыль
Нужно открытое железо, а не костыли.
для открытого железа нужен новый Торвальдс, а то сейчас там разработчики живут только с закрытого IP и не занают как по другому, разве что "Столлманы" и "Танненбаумы" встречаются в каком-то количестве.
Столлман и тот говорил, что открытое железо - с ним не всё так просто
Чушь собачья. Мало что-ли примеров, когда в линуксе дыры годами не закрывали - не потому, что не могли, а потому, что Неуловимый Джо?
Может Джо потому и неуловим, что мало охотников его ловить с развлечением в виде реверс-инжиниринга по каждому чиху?
> Так как разные процессорные потоки используют общий буфер RSB, потенциально атака SpectreRSB может применяться не только для выявления значений закрытых областей в текущем процессе для обхода ограничений sandbox-изоляции, но и для организации утечки данных из других процессов и виртуальных машин, а также для обхода средств изоляции кода и данных, предоставляемых технологией Intel SGX (Software Guard Extensions)Так вот о чем предупреждал Teo...
Тео про другое говорил - что при наличии HT время измерять можно с точностью в несколько тактов, не глядя ни на какие часики. Т.е. защиты построенные на загрублении таймеров идут лесом, только работать мешают.
Твой Тео вообще любитель повоевать с ветряными мельницами
Столько якобы защит, столько они там всего предусмотрели, такое-то от всего этого замедление... и всё равно решато решетнявое наравне со всеми....
HyperThreading отключили, теперь предсказания вырубить? :D Да можно - хрен ли. )
Хорошему софту и проца класса Пень3 хватит. )
Интересно, что будет с видяхами - какие там весёлости можно будет заполучить через ОпенКЛ/КУДА
Что там с Core i9 ? Вроде писали, ему на эти спектры пох.