Комментарии 138
Если найдут ещё несколько аналогичных уязвимостей, патчи для которых угробят производительность не на 15%, а на 200% — тогда это вполне станет возможным.
Сколько лет и денег потребует она?
Возможно, стоимость разработки будет сопоставима с бюджетом фильмов Матрица 2/3 ($300 млн).
Данный рынок слишком энертный для таких подвижек.
Потому и развелось в последнее время столько «кроссплатформенных» фреймворков, что все архитекуты стали похожими, как близнецы… вот только и уязвимости у них — тоже похожие…
Речь же не идёт о том, чтобы перекомпилировать что-то. Нужно перепиcывать. Под совсем-совсем другую парадигму.
Требования к предсказанию условных переходов есть у свежего ресурсозатратного софта.
Древний софт написанный 5-10-15 лет назад на современных процах будет работать вполне нормально в режиме эмуляции без всяких предсказаний.
А свежий ресурсозатратный… Ну это сильно специфичная штука, и надо конкретные примеры смотреть.
Браузеры конечно очень пострадают и игры. Это основные массовые проги которые пострадают от выключения предсказаний.
Всё не массовое можно запускать в закрытых экосистемах. Где левого опасного софта нет.
Если уж на то пошло, мне не понятно, почему не сделать отдельное ядро без предсказаний на котором вертится весь не доверенный софт и отдельно ядра мощные с предсказаниями, но доступ к которым есть у ограниченного количества софта. Может это обсуждалось и я просто пропустил?
Можно конечно возразить: «Откуда возьмутся деньги? Кто это оплатит?», отвечу заранее — вот вы, граждане, и оплатите. И сейчас вы платите, и потом будете платить. Сейчас вы оплачиваете ипотеку (за бетонную конуру) и автокредит отечественному банку, банк отдаёт заёмные средства другому банку, а тот, в свою очередь, переводит очередной многомиллиардный транш, сбрасывая с вертолёта мешок с деньгами для очередного единорога из золотозвончатой долины, делающему убероподобный трэш с котиками и блокчейном. Политика у инвесторов такая — переводить деньги на всяческую ерунду. Чтобы гарантированно ничего полезного не выросло. Достаточно лишь изменить политику
Однажды до них дошло, что вместо инвестиций в многолетние разработки и выпуск качественного продукта можно делать дерьмо, потратив большую часть денег на пиар и убеждение хомячков в огромной нужности продукта, чем серьезно сократить время окупаемости.
Так и живем.
Например, архитектура VLIW переносит задачу планирования параллельного выполнения соседних команд на компилятор. А последний знает больше о коде, чем процессор, потому может более вольно менять порядок инструкций.
В итоге получаем отсутсвие предсказателя перехода и увеличение вычислительных модулей.
Конечно, вероятность абстрактной уязвимости ненулевая, однако она ниже. Ибо меньше скрытых сложнодетерменированных блоков.
А последний знает больше о коде, чем процессор, потому может более вольно менять порядок инструкций.Ни фига он не знает о коде. Именно потому потонул Итаник. Компилятор может только строить догадки — понять какие проверки срабатывают чаще, а какие реже — ему не дано. И очень часто он это делает неверно.
Потому производительность VLIW-процессоров в однопоточных программах и близко не приближается к производительности суперскаляров.
А вот если бы мы могли освоить многопоточность «по настоящему» (не 2-3-4 потока, а сотни потоков, которые программы могли бы эффективно использовать) — то всё можно было бы сделать сильно по-другому… но тут нужно переписывать не одну-две программы, а вообще всё, что за десятелетия наработали… тут бюджетами в сотни миллиардов не отделаться…
Так что может быть тут тоже всё решится в итоге перекидыванием ответственности на разработчика, пишущего вместо привычного условия что-то типа
if ( myVar == 10 :likely(true) && theirVar > 20 :likely(false) ) {
?Раньше я и сам использовал __builtin_expect() там, где это могло помочь — на in-order PowerPC.
Так вот, к вашему сведению — PGO это и есть механизм, позволяющий компилятору не гадать, а знать, что, куда и сколько ходит по переходам.
Итаник потонул по многим причинам, но это не значит что заложенные в нем идеи — плохи.
Маркетинг, бессмысленный и беспощадный, как и сама x86…
Вы сей комментарий пишете из программы собранной с PGO
Пруфы?
PGO это и есть механизм, позволяющий компилятору не гадать, а знать, что, куда и сколько ходит по переходам.
PGO плох тем, что:
Использует апостерионую информацию. Компилятор не знает ничего о переходах, пока не будет сделано профилирование кода. А это довольно долгий и ответственный процесс.
Предсказания становятся захардкожены. Если в реальном сценарии использования программы статистика переходов будет другой, то получим падение производительности.
Аппаратный предсказатель же позволяет упростить компилятор, упростить систему команд и добавить гибкости в процессе работы программы.
Итаник потонул по многим причинам, но это не значит что заложенные в нем идеи — плохи.Нет — он потонул потому, что его архитектура не имеет смысла. Предполагалось, что компилятор сможет устроить параллелизм на уровне инструкций. Причём по нарастающей: 3 инструкции, 6 инструкций… 66 инструкций за такт… А оказалось — что это невозможно. 2-3 инструкции, которые иногда может вытащить суперскаляр — это предел для прохо параллелящегося алгоритма.
А если алгоритм параллелится хорошо, то он, с вероятностью 99%, хорошо ложится и на GPU — и Итаник снова «не при делах».
Просто неправильно была проведена изначальная оценка: считалось, что Итаниум будет хорошо себя вести на 90% задач, а оказалось — что на 10%, в лучшем случае…
Кстати, 2-3 за такт это для CISC, RISC это 3-5 для хорошего суперскаляра, а в случае MISC/микрокода до десяти доходит.
И тем не менее Intel Core жрут до 4 инструкций за такт, и интел обещает сделать до 5 у Sunny Cove, подняв этим производительность. Просто так бы такое не делали.Делают — потому что могут. Даже если в среднем вы можете исполнить 2-3 инструкции, но иногда (пусть редко) — получается 4-5, то для суперскаляра — это имеет смысл. Потому что если не получилось 4-5 — то вы особо ничего не потеряли. Для VLIW'а же — это катастрофа: если вы заложились на 4 инструкции за такт, а можете выдать всего две — то вы уполовинили, тем самым, кеш, память, пропускную способность шины и так далее.
Кстати, 2-3 за такт это для CISC, RISC это 3-5 для хорошего суперскаляра, а в случае MISC/микрокода до десяти доходит.Это всё равно не моможет VLIW'у. Ему важно не до скольки оно «доходит», а до скольки оно «опускается». Если можете выдержать 3 инструкции на такт устрйчиво — молодец, VLIW уже может бороться с суперскаляром, сможете устойчиво сделать 6 — и суперскаляр будет «плакать в сторонке».
Но… не получилось. «Не шмогли» разработчики компиляторов это сделать для «типичного кода». А для «нетипичного» — для него GPU, TPU и прочие «модные штучки» есть…
Это, кстати, суперскаляр против VLIW только. Если же у нас есть спекулятивные исполнения — то всё ещё хуже: один промах мимо кеша — отправляет процессор «в аут» не на одну сотню тактов. Если спекуляции у нас есть — мы можем в это время заняться тем, что должно бы случится после того, как эти данные «подвезут» (и выполнить пусть не сотни — но как минимум десятки команд спекулятивно), если спекуляций нет — всё, приплыли… ждать — и без вариантов…
Для VLIW'а же — это катастрофа: если вы заложились на 4 инструкции за такт, а можете выдать всего две — то вы уполовинили, тем самым, кеш, память, пропускную способность шины и так далее.Многие считают что VLIW отменяет необходимость в декодере инструкций. Это не так. Кодовые слова произвольной длины резко убирают все «дыры» в кешах, повышая плотность кода, и при этом не требуют особо сложной схемотехники.
Если спекуляции у нас есть — мы можем в это время заняться тем, что должно бы случится после того, как эти данные «подвезут» (и выполнить пусть не сотни — но как минимум десятки команд спекулятивно), если спекуляций нет — всё, приплыли… ждать — и без вариантов…Опять же, не обязательно. Barrel-архитектура с пропуском застрявших потоков исполнения, и общий для всех потоков конвейер (а VLIW не обязывает процессор не иметь конвеер вообще, к слову) может серьезно так поднять производительность. При этом, без логики предсказывающей переходы и внеочередного исполнения.
UPD: Только сейчас дошло, что вы о производительности одного потока с исключительно последовательно выполняемыми командами. В подобном случае и внеочередное исполнение мало поможет, если каждая последующая инструкция зависит от предыдущей.
Насколько я понимаю, для VLIW нужно компилировать свой бинарник под каждую модель процессора, если есть какие-то отличия в числе исполнительных устройств. Очень "хрупкая" архитектура.
X86 в этом отношении весьма неплох — в одном и том же коде разные процессоры по-своему распределяют инструкции по своим исполнительным устройствам. Хотя это аппаратно сложнее, а значит медленнее и прожорливее.
Тут очень тонкий момент. VLIW можно представить как более низкоуровневый процессор, где убрали предсказатели перехода и позволили сделать параллельное выполнение соседних команд. Т.е. говоря другими словами: предсказания перехода ушли из процессора, то есть уязвимости типа Spectre не могут там появиться архитектурно. Последнее важно, так как на тех же ARM/x86 от уязвимостей не уйти просто потому, что есть предсказатель этих самых переходов.
Далее: по сравнению с серединой нулевых, сейчас намного больше программ, которые не компилируются сразу в машинный код. То есть в программах на Java/.Net/Python/JS не придется менять ничего, кроме native кода. Более того, даже компиляция зачастую работает через LLVM (кстати, через него работает Kotlin Native и .Net Core). Или другими словами: по сравнению с 2005 годом не придется перекомпилировать столько ПО. Придется лишь серьезно обновить не такой большой набор технологий.
Однако и тут всё стало проще. Всё дело в том, что аналог предсказателя переходов есть в той же Java. В процессе работы программы она замеряет "горячие точки" и переставляет иструкции и т.д. Причем, что очень круто, та же Java может позволить себе намного больше вольностей, по сравнению с аналогичным модулем на процессоре.
Однако, чтобы подытожить текст выше:
- От предсказателей перехода могут избавиться только процессоры с более явным параллельным выполнением, такие как на архитектуры LLVM.
- Современное ПО намного больше готово к работе с такими процессорами, чем 10-20 лет назад.
А последний знает больше о коде, чем процессор, потому может более вольно менять порядок инструкций.
Не может. А вот OoO процессор может переупорядочивать чтения и записи в память, выполнять код без остановки, когда предыдущие инструкции ещё ждут данных.
В итоге получаем отсутсвие предсказателя перехода и увеличение вычислительных модулей.
А куда он денется? Есть конвейер — нужен и предсказатель (если не хотим столлы на каждом бранче).
Есть конвейер — нужен и предсказатель
Да нужен, однако я говорю, что сейчас эту задачу может взять на себя прикладное ПО. И это было намного сложнее 10 лет назад.
Задам еще вопрос: в чем принципиальный плюс встроенного предсказателя переходов в чип? Почему его нельзя поместить в ту же JVM/CLR/LLVM ?
Не может. Бранчи в коде в среднем встречаются каждые 4 (*YMMV) инструкции.
Как вы это себе представляете? Современный BP — сложный, многоуровневый самообучающийся механизм. Точнее их несколько штук, каждый на свой случай — есть loop / indirect / return address predictor и т.д.
Авторы Elbrus попытались обойтись без предсказателя за счёт усложнения архитектуры и повышенного энергопотребления, но без предсказателя им не светят какие-либо значительные частоты.
mcst.ru/files/575724/070cd8/50dc38/000000/abdurazakovvolinlaptev-opyt_realizatsii_predskazaniya.pdf
>> в чем принципиальный плюс встроенного предсказателя переходов в чип
Предсказатель, знаете ли, предсказывает будущее. Вычисления отстают на 5-10 тактов (современных чипах) от чтения инструкций из кэша. Команды по предсказанному адресу уже загружены в конвейер прежде чем будет известно какая ветка нужна.
В CELL есть инструкция hbr, которая позволяет «предсказать» бранч, только вот эта информация дойдёт до fetch-ера как минимум через 15 тактов (30 инструкций). Не очень быстро, да?
Авторы Elbrus попытались обойтись без предсказателя за счёт усложнения архитектуры и повышенного энергопотребления,…
Ваша предложение звучит так, как будто в Эльбрусе переусложнённая архитектура и повышенное энергопотребление, но на самом деле всё наоборот.
но без предсказателя им не светят какие-либо значительные частоты.
Наличие предсказателя переходов никак не влияет на частоту процессора. Если вы про конечную производительность, то действительно в некоторых алгоритмах эвристический предсказатель переходов лучше, чем просто широкий конвейер, а вот в некоторых наоборот.
Ваша предложение звучит так, как будто в Эльбрусе переусложнённая архитектура и повышенное энергопотребление, но на самом деле всё наоборот.
Почитайте pdf-ку, которую я указал. Достаточно введения.
Архитектура Elbrus действительно переусложнённая для VLIW. E2K навечно остался в 90-х годах. Итаниум хотя бы уже отмучился.
Наличие предсказателя переходов никак не влияет на частоту процессора
Влияет. Их схема работы с переходами просто не справится с длинным конвейером. Производительность будет страдать.
Предсказатель, знаете ли, предсказывает будущее. Вычисления отстают на 5-10 тактов (современных чипах) от чтения инструкций из кэша. Команды по предсказанному адресу уже загружены в конвейер прежде чем будет известно какая ветка нужна.
Эльбрус тоже умеет заранее загружать необходимую инфу, а также избавляться от небольших условий, исполняя ветки параллельно. Эльбрус активно спекулирует при работе.
Эльбрус активно спекулирует при работе.
Сложно, медленно и энергозатратно :)
Эльбрус активно спекулирует при работе.А значит тоже потенциально подвержен Spectre.
Или я ошибаюсь?
По хорошему-то нужно научиться писать так, чтобы программы могли исполняться на сотнях (а в перспективе — и на тысячах) медленных ядер, но… это ж не x86 придётся похоронить, это придётся терабайты уже написанного кода похоронить — кто это может себе позволить?
Например, каждой странице назначаем ключ/маску, в результате разные процессы будут видеть память по разному. И потребуется изменить только ОС, причём в сравнительно небольших объёмах.
Да даже и спекулятивное выполнение не обязательно выкидывать.Чукча — не читатель? Как раз речь в обсуждаемой статье о том, что практически скрыть «следы» спекулятивного исполнения — не реально.
Слишком много в процессоре разных буферов, кешей и прочего, на которые оно может повлиять. И архитектура команд процессора — тут вообще дело 10е.
И потребуется изменить только ОС, причём в сравнительно небольших объёмах.Если бы. Чтобы «следов» не оставалось потребуется при каждом системном вызове все спекуляции и, главное, все буфера, где спекуляции могут «насладиться» сбрасывать. Это радикально изменит весь дизайн ОС. Потому что сделает системные вызовы баснословно дорогими — а это, как бы, полная противоположность тому, что есть сейчас и под что весь существующий софт заточен…
Может быть сработает простой трюк: выключить вообще всякие спекуляции при исполнении кода ядра — тогда замедление скорости работы ядра будет многократным, но, возможно, терпимым.
Остальное — паллиатив…
Для чувствительных данных (ключи, пароли), даже сейчас, без аппаратной поддержки, возможна программная защита (данные под маской/ключом, маска/ключ достаточно часто меняется). В принципе, полностью аналогичная обычным методам защиты от утечки по побочным каналам.
Ещё раз, чистить не обязательно, изменяем процессор так, что каждый процесс ОС видит данные по конкретному физическому адресу разные, везде разные, во всех кэшах, и всё.Блин. Вот типичное «мыши, станьте ёжиками». Как вы это сделе представляете? Кеш, он, знаете ли, меньше памяти — а значит, в соотвествии с известным приципом разные участки памяти будут мапироваться на одинаковые места в кеше. Но кроме обычных кешей в процессоре есть масса разных других состояний, на которые тоже можно влиять, а так как эти вещи по объёму меньше — то и проблема стоит острее.
Процесс, которые что-то выясняет с помощью спекулятивного выполнения, выяснит нечто своё, ну и Бог с ним.В том-то и дело, что поскольку разные участки памяти с неизбежностью мапятся на одно место в кеше — то он сможет выяснить не «что-то своё», а «что-то про все участки памяти, замапленные в это же место».
Добиться того, чтобы этого не происходило можно только одним способом — выделив каждом процессу своё ядро… но даже этого не хватит! Потому что останется ещё операционная система, которая тоже выполняется на процессоре со спекулятивным исполнением и которую тоже можно использовать для передачи данных.
Вот если сделать так, чтобы операционка выполнялась на процессоре без спекулятивного исполнения и вдобавок к этому, ещё и все процессор выполнялись на разных физических ядрах (или полностью сбрасывать все кеши при переходе от одного процесса к другому, что, фактически, то же самое)… тогда, возможно утечек удастся избежать.
Для чувствительных данных (ключи, пароли), даже сейчас, без аппаратной поддержки, возможна программная защита (данные под маской/ключом, маска/ключ достаточно часто меняется).Очень-очень сложно. Вы знаете как ключ для XBox360 находят? Уникальный, прошитый в процессор, никогда не выдаваемый наружу? Замером скорости функции memcmp. В прошивке, начиная с какой-то версии вместо memcmp используется посимвольное сравениение всех 16 байтов с занесением результата в 16 байн на выходе, потом их все or'ят и только потом сравнивают с нулём. Но это вы всё можете проделать только если на ассемблере пишите, а если у вас оптимизирующий компилятор — то всегда есть шанс, что он поймёт, что вся эта машинерия эквивалентна memcpy и вернёт её взад!
… Но это вы всё можете проделать только если на ассемблере пишите, а если у вас оптимизирующий компилятор...А это ничего, что всё прогрессивное человечество уже многие годы как придумало и использует memset_s()/explicit_bzero()/SecureZeroMemory()?
Но это для халявщиков, которым наплевать на побочные каналы, а при строгой смене масок/ключей, компилятор не может может вмешаться.
А это ничего, что всё прогрессивное человечество уже многие годы как придумало и использует memset_s()/explicit_bzero()/SecureZeroMemory()?Ничего. Потому что это решает лишь мааахонькую часть задачи: как прибрать за собой, чтобы следов не осталось. Если вы можете следить за процессом — у вас появляется масса возможностей, которые эти функции не решают. В частности проблему, описанную мною выше — они не решают тоже.
Таким образом спекулятивное выполнение другого процесса будет отличаться, т.к. для него будут приходить иные данные в процессор.То есть, в частности, разделяемые библиотеки перестанут быть разделяемыми? Чуть лучше, чем полный сброс всего, но тут мы упираемся в необходимость хорошо всё рандомизировать. У L1 и без того задержки изрядные.
И по прежнему остаётся возможность использовать ядро для передачи информации…
Но это для халявщиков, которым наплевать на побочные каналы, а при строгой смене масок/ключей, компилятор не может может вмешаться.Кто ему запретит?
То есть, в частности, разделяемые библиотеки перестанут быть разделяемыми?Если ключи/маски по страницам в TLB, то разделяемые страницы разделяемых библиотек останутся разделяемыми, а приватные приватными. Даже копирование-при-записи будет пахать.
И по прежнему остаётся возможность использовать ядро для передачи информации…Это ж вряд ли. Хотя и зависит от организации конкретного ядра.
Кто ему запретит?Как бы когда пишут константы и/или освобождают память, у компилятора ручки свободны. А когда меняют ключи/маски у компилятора соблазна нет, данные реально изменяются, кроме того эти изменения независимо контролируются и потенциальные ошибки компилятора будут обнаружены.
Если ключи/маски по страницам в TLBTLB — один из самых маленьких и медленных кешей. Потому что полностью ассоциативный. Именно потому L1/L2 кеши обычно используют логический, а не физический адрес.
Вот кэш МОП, тот да, виртуализирован, но кэш инструкций в контексте Spectre рассматривать странно.
P.S. Впрочем, сделать L1D с виртуальными адресами, может оказаться неплохой идеей борьбы со Spectre (зачатком идеи).
Вот если сделать так, чтобы операционка выполнялась на процессоре без спекулятивного исполнения и вдобавок к этому, ещё и все процессор выполнялись на разных физических ядрах (или полностью сбрасывать все кеши при переходе от одного процесса к другому, что, фактически, то же самое)
Достаточно выделять на процесс свой участок кэша, по сути так же, как выделяется память. Возможно, даже не физический участок кэша, а каким-то образом виртуализованный.
Железо потребуется заменить, но архитектура, система команд лишь немного расширится, а может и останется прежней.
Уязвима не архитектура (набор инструкций и регистров), а многие реализации — т.е. микроархитектура. В случае с RISC-V автор out-of-order ядра Boom рассказывал о теме:
https://content.riscv.org/wp-content/uploads/2018/05/13.00-13.15-Celio-Barcelona-Workshop-8-Talk.pdf
"Securing High-performance RISC-V Processors from Time Speculation" 2018-05
https://www.esperanto.ai/securing-high-performance-risc-v-processors-from-time-speculation-risc-v-barcelona-workshop/
We can still build high-performance, speculative processors
that are protected against timing attacks…
Don't leak any observable side-effects in the machine if speculation is aborted. Avoid bandwidth interference between different Time Domains
Any shared resource can leak time… resources must be deterministically released on a misspeculation
Еще одна публикация о Spectre в Risc-v реализации boom_cpu
Replicating and Mitigating Spectre Attacks on a Open Source RISC-V Microarchitecture
Abraham Gonzalez, Ben Korpan, Jerry Zhao, Ed Younis and Krste Asanović (University of California, Berkeley) paper
https://carrv.github.io/2019/papers/carrv2019_paper_5.pdf
https://carrv.github.io/
А фактор легаси работает до сих пор. Программы — они ведь более ценные, чем железяки.
Ну и второй немаловажный момент, на самом деле очень мало шансов, что новая хорошая архитектура окажется на самом деле хорошей, а не как обычно — с кучей недостатков и проблем, которые выявляются уже в процессе запуска, и на которые в старой архитектуре были костыли/заплатки.
Всё верно, но ведь ничего не делать со Spectre и оставить всё как есть тоже нельзя.
Желание все выбросить и написать всё правильно выдает в комментаторе юношеский максимализм.
С другой стороны, сегодня большинство серверов состоят из полностью опенсорсного кода (за минусом фирмвари), а клиенты всё более сводятся к браузеру. Всё это скомпилировать из исходников в другую архитектуру — вполне решаемая задача. x86 сегодня выигрывает скорее именно в стандартизированной фирмвари, наличии виртуализации и хороших периферийных интерфейсах. Благодаря этому один дистрибутив ОС разных вендоров без изменений заводится на разных материнках, и автоматом подхватывает всё железо, чего ARM-у и не снилось.
все процессоры со спекулятивным выполнением всегда будут подвержены различным атакам боковых каналов, несмотря на методы частичной защиты, которое могут быть реализованы в будущем.Вы можете хоть уперекомпилироваться, но это ничего это не изменит, так как все процессоры делятся на два непересекающихся класса:
1. Процессоры без спекулятивного исполнения, где 100500 уровней индирекции, порождённые архитектурными астронавтами, дико тормозят
2. Процессоры со спекулятивным исполнением, где избавиться от Spectre практически невозможно
Причём тут вообще x86? POWER и ARM точно так же подвержены Spectre, как и x86…
Спасибо, но я в курсе про универсальность Spectre. А отвечал я на комментарий про x86 (а не статью), и лишь хотел сказать, что "легаси isa x86" сегодня не так страшно, как 10 лет назад.
А вообще я думаю что Apple как производитель процессоров со своей архитектурой это быстро исправит. Потому всё остаётся как я и говорил.
Посмотрим. Только время покажет :)
Сама же идея что Apple может исправить фундаментальную проблему, потому что у них «своя архитектура», а Intel — не может, потому что… «ну тупыыыые» — тут неясно смеяться или плакать…
Apple выпускает устройства полностью прорабатывая как железо так и софт.
И в случае изменения архитектуры проца просто подгонит софт и ничего при этом не сломается.
Intel же выпускает только процессоры, и в случае изменения архитектуры процессора возникнет вопрос с тем что внезапно перестанет работать какой-то софт, нужно будет куча исправлений.
Вспомните как Apple перешла с PPC на Intel. Они просто взяли и сказали — всё уже готово, забирайте. И у людей весь нужный софт работал и сразу был под рукой. А это полная смена архитектуры, пересборка всей ОС и модулей.
Я также уверен что Apple скоро переведёт маки на свой проц. Возможно на комбинацию в паре с Intel процом для совместимости со старой архитектурой или с каким-нибудь аппаратным эмулятором этой архитектуры, кто знает.
В iOS ещё есть другой момент — это закрытая ОС на которую невозможно поставить софт вредящий системе если пользователь сам сознательно себя не подвергает опастности. В случае с Windows это не так, увы.
Вспомните как Apple перешла с PPC на Intel. Они просто взяли и сказали — всё уже готово, забирайте. И у людей весь нужный софт работал и сразу был под рукой. А это полная смена архитектуры, пересборка всей ОС и модулей.И эмулятор PPC.
Вернее:
В 1994 году Apple перешла с архитектуры Motorola 68000 на PowerPC, а в 2006-м — с PPC на Intel. В первом случае компания предлагала эмулятор, а во втором — динамический транслятор Rosetta.
+
... была последняя версия системы, в которой можно было запускать софт, написанный для PPC, через эмулятор Rosetta.
IA64 проектировался тогда же, когда Intel обжигалась об Rambus. Поэтому они и смогли вляпаться в такую авантюру.
Помню как первые модели 64-битных процессоров от Intell провалились из-за тормозной эмуляции, и что 64-битные процессоры от AMD стали успешными благодаря аппаратной поддержке x86.
И разве на x86 была эта проблема?
ЗЫ В какой-то мере, это может даже помочь. Уж больно современный софт прожорливым стал.
в ближайшее время будет все больше подобных атакА эти «атаки» вообще были?
Даже если и нет — то будут. Использовать эти уязвимости не очень просто, и потребуется время и ресурсы на то, чтобы создать эффективные эксплойты. Если сейчас атаки традиционным способом (через уязвимости софта) дешевле, то в эксплойт для Spectre могли особо не вкладываться. Но вот после таких новостей, когда становится понятно, что Spectre вряд ли когда-либо закроют, создание "вечного" эксплойта, который будет работать всегда и везде, и который невозможно заблокировать — вполне может стать достаточно привлекательным, чтобы вложить достаточно средств в его разработку.
А по поводу были или нет. Думаю, что в исследовательских целях был сделан не один дамп. На мой взгляд, проблема сейчас в том, что атакующему нужно знать, что искать в полученном дампе, и это сложнее чем осадить дамп памяти в каком-то кеше.
снижение точности таймераКак бы Intel изначально всё так и задумал, и в x86 изначально был бит отключения RDTSC для непривилегированных процессов. Конечно, его можно усложнить, скрестить с RDRAND.
Но, сдаётся мне, если сейчас базу RDTSC случайно изменять с частотой HZ (_SC_CLK_TCK), естественно, корректируя переменную смещения для системных вызовов clock_gettime()/gettimeofday(). То, если всё сделать разумно, Spectre не пройдёт ;)
можно вообще без RDTSC. Просто считать количество итераций цикла. Менее удобно и надёжно — но работает
Крайне стрёмный вариант, помню как игрушки для x286 носились с бешеной скоростью на x386, а на x486 вообще становились неиграбельны. :(
Кодите тоже без фреймворков, чтобы без примитивов?
Не холивара ради. Я программирую на том самом, седьмом ещё Дельфи. С детства почти, очень профессионально, логику с интерфейсом не мешаю. Сегодня работаю, а не давным-давно работал. И мне таки неудобно. Не хватает современных, классических уже примитивов. Огромное количество нелепый телодвижений нужно, чтобы сделать, к примеру, аналог лямбда-функции. Или сделать ORM, (писал для последнего проекта) — неудобно, нету аннотаций. Без дженериков (нету их) — боль. А Вы говорите, примитивы не менялись… И даже так, "в режиме эмуляции современности", получаются системы намного более сложные в пересчёте на час рабочего времени и куда как более гибкие, чем тогда.
Бэйсик — особая история. Тот, с которого я начинал программировать, имел только глобальные переменные. Только глобальные, Карл! Переменные на стеке? Рекурсия? Не слышали… Шестнадцать лет назад щупал vb, там стало намного лучше, но классы наследовать нельзя было. Абстракция, обобщения? Тьфу на вас ещё раз, обойдётесь!
То, что я вспоминаю старое время с теплотой не говорит о том, что "сидеть под голым досом и не стыдиться" было лучше. Может, нам-тогдашним, молодым, горячим, наивным и было в кайф, я не спорю. Было, мне так точно было. Но я вырос. Я решаю насного более сложные задачи, и делаю это кратно быстрее. Я думаю об архитектуре, о трудоёмкости доработок, о читаемости кода. И в этом намного больше удовольствия! Я могу больше. Свой опыт, чужой опыт. И то, и другое часто выражено в примитивах, абстракциях. Новых примитивах, новых абстракциях. И они реально создают моё качество работы и её эффективность .
А старый, "добрый" Дельфи — я его конечно хорошо умею и очень ему благодарен, но приходится таки время от времени запускать Идею и поднимать себе настроение Джавой. Кайф, честно...
Должна быть одна тысяча строк кода а остальное должно быть реализовано аппаратно
intel на это и напоролась, обойти аппаратную фичу не может полностью
Не должно быть миллионов строк кода. Должна быть одна тысяча строк кода а остальное должно быть реализовано аппаратно. В FPGA или ещё как — не суть важно.Посмотрите на историю изменений этих строк — сколько раз там находились ошибки, что-то исправлялось и доделывалось.
А теперь представьте что изменение это не програмный патч, а необходимость переделывать архитектуру на низком уровне. Насколько сложней будет внедрять патчи?
Сколько времени потребуется программисту чтобы написать аналитическую систему комплексной стат.обработки с чтением\сохранением разных форматов данных и построением графиков\диаграмм на Бейсике 80-х годов и на современном Питоне с библиотеками?
Задачи принципиально усложнились.
Когда PHP начал распространятся 20 лет назад сайты состояли из нескольких шаблонов и нескольких форм и всё, структура страниц была проще, ни о какой динамической подгрузке, адаптации под мобильные, кучи кастомизации речи не шло.
Задачи принципиально усложнились.
Смотря с каким периодом сравнивать. Если брать совсем уж зарождение отрасли, то да, принципиально усложнились. Если брать чуть позже, например, уже вторую половину 1990-х, то там не было некоторых современных отраслей IT, например, BigData и Machine Learning, но на 90% решаемые задачи вполне себе соответствовали нынешним, естественно, с поправкой на окружение тех лет. Т.е. вместо веба клиент-серверные и распределенные десктопные приложения, вместо шустрых интернетов локальные сети предприятия и модемы.
Инструментарий разработки десктопных приложений в те годы был не хуже, а то и лучше, чем сейчас его аналоги для веб-приложений. При этом скорость реализации функционала, я не ошибусь, если скажу, что была заметно выше.
Инструментарий разработки десктопных приложений в те годы был не хуже, а то и лучше, чем сейчас его аналоги для веб-приложений.Десктопное приложение тогда обычно разрабатывалось под конкретную операционную систему и разрешение экрана, а веб-приложение должно сейчас работать и на планшете и на телефоне и на десктопе в разных браузерах и разрешениях, к тому же права такого приложения на действия в системе существенно ограничены из соображений безопасности.
Так что учитывая кросс-платформенную поддержку и отзывчивость дизайна, сложность системы в целом тоже существенно увеличилась.
Сколько нужно времени чтобы просто получить промпт питона?Да примерно столько же.
Да, с какой-нибудь IDE всё будет посложнее, но она и возможности даёт несопоставимые с тем бейсиком.
Сейчас миллиарды транзисторов невозможно полностью контролировать
. Не должно быть миллионов строк кода. Должна быть одна тысяча строк кода а остальное должно быть реализовано аппаратно.
Какая разница, где у вас будут ошибки, если ошибки неизбежны?
Не должно быть миллионов строк кода. Должна быть одна тысяча строк кода а остальное должно быть реализовано аппаратно.А аппаратный код собирают по весне с чайных деревьев?
Должна быть одна тысяча строк кода а остальное должно быть реализовано аппаратно. В FPGA или ещё как — не суть важно.Вы же в курсе, что микросхемы проектируются посредством написания кода на языке Verilog, да? )
Таким образом имеем проверку исходного кода, поиск, выявление и преследование тех, кто уязвимостями пользуется.
Для тех кто собирается комментировать про спецслужбы — в их арсенале наверняка есть как более продвинутые так и более архаичные методы получения информации, и да, то что считается незаконным для обычных граждан может быть позволено и оправдано для использованияя спецслужбами, будь то насилие, кража информации т.д. в «высших» целях. Вопрос о преследованиях политических оппонентов и всего с этим связанного находится скорее в плоскости морали и его я обсуждать не намерен.
Более практичным и дешёвым подходом будет охота на преступников.И государства за тысячелетия охоты за преступниками так и не смогли полностью их искоренить.
Это по-сути задача «снаряда и брони». Чем сильней становится защита, тем изощренней находятся способы ее обойти.
Мой комментарий не о нахождении новых уязвимостей, он об использовании уязвимостей как таковых, это ведь осознанный выбор.
По-адекватному стоило бы снизить цены на текущие и прошлые поколения процессоров Интел. И разрабатывать новые.
По сути продают процессоры с вечной дырой в защите.
Не зря по слухам Эпл уходит на RISC
А если производительность проседает сильно, нельзя ли просто ввести команды выключения-включения спекулятивного выполнения, чтоб код, который отвечает за что-то критичное по безопасности, отключал спекулятивное выполнение, а потом его снова восстанавливал?
А можно просто выключить спекулятивное выполнение? Для многих задач, если производительность упадёт раза в два, а не в тысячу, но при этом такие атаки будут исключены, то и ладно.Там разница раз в десять будет. Современные процессоры делают очень много разных спекуляций на разных уровнях. Если из выключить все — будет очень больно.
Тезис N1: Spectre (S) и Meltdown (M) являются прямым следствием роста сложности реализаций процессоров. Современный ЦПУ обладает сумасшедшим уровнем сложности. В частности, SM-уязвимость возникает на стыке казалось бы независимых компонентов: предсказание ветвлений, спекулятивное выполнение, кэширование, механизмы организации безопасности, механизмы организации адресных пространств. Их можно закрыть аппаратно. Но! Очень сложно гарантировать отсутствие подобных уязвимостей при сохранении текущего уровня сложности ЦПУ.
Тезис N2: Уязвимости типа SM можно закрыть программно на уровне ОС. SM дает возможность читать из той части адресного пространтства текущего процесса, которая принадлежит ядру. Соответственно, нужно сделать так, чтобы в этой части адресного пространтства не было критически важной информации. Соответственно:
Вариант а) Микроядро в основе системы. В истинных микроядрах в пространстве ядра нет ничего интересного для чтения вредоносом. Все что интересно, находится в адресных пространствах ДРУГИХ процессов, куда нужно сначала переключится. Так что туда с помощью SM не залезть
Вариант б) Для Linux-подобных систем. Ядро выгружается в свое отдельное виртуальное адресное пространство (свой процесс). В пользовательских процессах остается только заглушка, которая по системному вызову (прерыванию) производит переход в виртуальное адресное пространство ядра и передает туда же управление. Опять же, прощай SM.
Так что закрыть SM чисто программно можно на уровне ОС. НО! Это не дешево! Потери производительности будут значительными! Стоимость холосного системного вызова выростет как минимум в 5-10 раз. И на это еще наложится трэшшинг кэша и TLB. Так что совокупные потери производительности могут легко дойти до величин в районе в два раза.
кроме RISC и российского «Эльбруса»
1. ARM — RISC и он частично подвержен Spectre
2. У Эльбруса нет предсказателя переходов и он действительно не подвержен большому классу уязвимостей. Тем не менее теоритически он может быть подержен сходим уязвимостям.
Исследователи из Google: для защиты от Spectre требуется изменение архитектуры процессоров, программные патчи не помогут