Comments 138
Хороший повод похоронить древнюю и кривую архитектуру x86 с кучей legacy и перейти на что-то более современное, разработанное с нуля и с учетом потребностей современного мира. Только что-то не верится что это случится…
Если найдут ещё несколько аналогичных уязвимостей, патчи для которых угробят производительность не на 15%, а на 200% — тогда это вполне станет возможным.
Сколько лет и денег потребует она? Каков потенциальный доход? Сколько маркетинга потребуется, чтобы вытряхнуть пользователей из старого? Есть причины, почему этим никто не занимается.
Сколько лет и денег потребует она?
Возможно, стоимость разработки будет сопоставима с бюджетом фильмов Матрица 2/3 ($300 млн).
300 лямов это такое копье что даже смешно)(у интела на R&D в 17 году бюджет 13 лярдов) там нереальное количество денег придется вбухать всему it сектору на переход. и в разработку чтобы получилось сопоставимо по качетсву/сложности.
А ещё толпу софта переписать под новую архитектуру.
В современном мире это уже не проблема. Подавляющее большинство современных фреймворков кроссплатформенные. А для legacy можно делать эмуляцию.
Корпоративный сегмент очень «любит» и эмуляцию. и виртуализацию, особенно всякие вещи с шифрованием и т.д.
Данный рынок слишком энертный для таких подвижек.
Данный рынок слишком энертный для таких подвижек.
Подавляющее большинство современных фреймворков кросс-платформенные и использовать из на медленных процессорах без спекулятивного исполнения невозможно.
Потому и развелось в последнее время столько «кроссплатформенных» фреймворков, что все архитекуты стали похожими, как близнецы… вот только и уязвимости у них — тоже похожие…
Речь же не идёт о том, чтобы перекомпилировать что-то. Нужно перепиcывать. Под совсем-совсем другую парадигму.
Потому и развелось в последнее время столько «кроссплатформенных» фреймворков, что все архитекуты стали похожими, как близнецы… вот только и уязвимости у них — тоже похожие…
Речь же не идёт о том, чтобы перекомпилировать что-то. Нужно перепиcывать. Под совсем-совсем другую парадигму.
Нет не нужно.
Требования к предсказанию условных переходов есть у свежего ресурсозатратного софта.
Древний софт написанный 5-10-15 лет назад на современных процах будет работать вполне нормально в режиме эмуляции без всяких предсказаний.
А свежий ресурсозатратный… Ну это сильно специфичная штука, и надо конкретные примеры смотреть.
Браузеры конечно очень пострадают и игры. Это основные массовые проги которые пострадают от выключения предсказаний.
Всё не массовое можно запускать в закрытых экосистемах. Где левого опасного софта нет.
Если уж на то пошло, мне не понятно, почему не сделать отдельное ядро без предсказаний на котором вертится весь не доверенный софт и отдельно ядра мощные с предсказаниями, но доступ к которым есть у ограниченного количества софта. Может это обсуждалось и я просто пропустил?
Требования к предсказанию условных переходов есть у свежего ресурсозатратного софта.
Древний софт написанный 5-10-15 лет назад на современных процах будет работать вполне нормально в режиме эмуляции без всяких предсказаний.
А свежий ресурсозатратный… Ну это сильно специфичная штука, и надо конкретные примеры смотреть.
Браузеры конечно очень пострадают и игры. Это основные массовые проги которые пострадают от выключения предсказаний.
Всё не массовое можно запускать в закрытых экосистемах. Где левого опасного софта нет.
Если уж на то пошло, мне не понятно, почему не сделать отдельное ядро без предсказаний на котором вертится весь не доверенный софт и отдельно ядра мощные с предсказаниями, но доступ к которым есть у ограниченного количества софта. Может это обсуждалось и я просто пропустил?
После чего новый процессор не продаётся, т.к. под него нет софта, поскольку вся эта эмуляция тормозит нещадно. Офисы-браузеры-мессенджеры убежать могут, но что посерьёзнее, где эмуляция угробит производительность, уже нет, а переписывать — иногда нужно сначала понять как работает.
Да сколько бы ни потребовала, это лучше, чем писать очередной, 100500ый по счёту JS фреймворк, и создавать 100501ый по счёту стартап по уберизации работы слесарей, или обработке фото, или чему-то столь же полезному.
Можно конечно возразить: «Откуда возьмутся деньги? Кто это оплатит?», отвечу заранее — вот вы, граждане, и оплатите. И сейчас вы платите, и потом будете платить. Сейчас вы оплачиваете ипотеку (за бетонную конуру) и автокредит отечественному банку, банк отдаёт заёмные средства другому банку, а тот, в свою очередь, переводит очередной многомиллиардный транш, сбрасывая с вертолёта мешок с деньгами для очередного единорога из золотозвончатой долины, делающему убероподобный трэш с котиками и блокчейном. Политика у инвесторов такая — переводить деньги на всяческую ерунду. Чтобы гарантированно ничего полезного не выросло. Достаточно лишь изменить политику
Можно конечно возразить: «Откуда возьмутся деньги? Кто это оплатит?», отвечу заранее — вот вы, граждане, и оплатите. И сейчас вы платите, и потом будете платить. Сейчас вы оплачиваете ипотеку (за бетонную конуру) и автокредит отечественному банку, банк отдаёт заёмные средства другому банку, а тот, в свою очередь, переводит очередной многомиллиардный транш, сбрасывая с вертолёта мешок с деньгами для очередного единорога из золотозвончатой долины, делающему убероподобный трэш с котиками и блокчейном. Политика у инвесторов такая — переводить деньги на всяческую ерунду. Чтобы гарантированно ничего полезного не выросло. Достаточно лишь изменить политику
UFO just landed and posted this here
У инвесторов политика — отбить деньги, чем быстрее, тем лучше.
Однажды до них дошло, что вместо инвестиций в многолетние разработки и выпуск качественного продукта можно делать дерьмо, потратив большую часть денег на пиар и убеждение хомячков в огромной нужности продукта, чем серьезно сократить время окупаемости.
Так и живем.
Однажды до них дошло, что вместо инвестиций в многолетние разработки и выпуск качественного продукта можно делать дерьмо, потратив большую часть денег на пиар и убеждение хомячков в огромной нужности продукта, чем серьезно сократить время окупаемости.
Так и живем.
Ох воу. Чтобы люди были рационалистами их нужно с детства так воспитывать, прокачивая логическое мышление, стратегическое видение и научный подход. Только тогда рухнет к черту копроэкономика.
Были слухи, что Apple откажется от x86 в пользу своих процессоров.
Нет абсолютно никакой гарантии что в новой архитектуре не будет уязвимостей такого уровня.
Например, архитектура VLIW переносит задачу планирования параллельного выполнения соседних команд на компилятор. А последний знает больше о коде, чем процессор, потому может более вольно менять порядок инструкций.
В итоге получаем отсутсвие предсказателя перехода и увеличение вычислительных модулей.
Конечно, вероятность абстрактной уязвимости ненулевая, однако она ниже. Ибо меньше скрытых сложнодетерменированных блоков.
А последний знает больше о коде, чем процессор, потому может более вольно менять порядок инструкций.Ни фига он не знает о коде. Именно потому потонул Итаник. Компилятор может только строить догадки — понять какие проверки срабатывают чаще, а какие реже — ему не дано. И очень часто он это делает неверно.
Потому производительность VLIW-процессоров в однопоточных программах и близко не приближается к производительности суперскаляров.
А вот если бы мы могли освоить многопоточность «по настоящему» (не 2-3-4 потока, а сотни потоков, которые программы могли бы эффективно использовать) — то всё можно было бы сделать сильно по-другому… но тут нужно переписывать не одну-две программы, а вообще всё, что за десятелетия наработали… тут бюджетами в сотни миллиардов не отделаться…
Про предсказывание частоты срабатывания сразу вспомнилось, как на Z80 старались выбирать между операторами JP / JR, потому что JP выполняется за постоянное время в 10 тактов, а JR при несрабатывании условия за 12, но при срабатывании всего лишь за 7.
Так что может быть тут тоже всё решится в итоге перекидыванием ответственности на разработчика, пишущего вместо привычного условия что-то типа
Так что может быть тут тоже всё решится в итоге перекидыванием ответственности на разработчика, пишущего вместо привычного условия что-то типа
if ( myVar == 10 :likely(true) && theirVar > 20 :likely(false) ) { ?Пробовали. Во времена Pentium4. Не работает. Разработчики слишком часто ошибаются. Уж не говоря о том, что мало кто знает о том, что эта фишка уже существует — но на практике я только в ядре Линукса видел её использование…
Да не скажите, что мало где используется. Вижу довольно часто. К тому же, как бы уже почти стандарт.
Процессоров общего назначения с branch hints уже никто не делает. Потому что это стало бессмысленно. Современный предсказатель не только лучше отработает, но и сможет адаптироваться к изменению поведения программы. Хотя конечно компилятор может положить код так, чтобы оптимизировать fetch.
Раньше я и сам использовал __builtin_expect() там, где это могло помочь — на in-order PowerPC.
Раньше я и сам использовал __builtin_expect() там, где это могло помочь — на in-order PowerPC.
Вы сей комментарий пишете из программы собранной с PGO
Так вот, к вашему сведению — PGO это и есть механизм, позволяющий компилятору не гадать, а знать, что, куда и сколько ходит по переходам.
Итаник потонул по многим причинам, но это не значит что заложенные в нем идеи — плохи.
Маркетинг, бессмысленный и беспощадный, как и сама x86…
Так вот, к вашему сведению — PGO это и есть механизм, позволяющий компилятору не гадать, а знать, что, куда и сколько ходит по переходам.
Итаник потонул по многим причинам, но это не значит что заложенные в нем идеи — плохи.
Маркетинг, бессмысленный и беспощадный, как и сама x86…
Вы сей комментарий пишете из программы собранной с PGO
Пруфы?
PGO это и есть механизм, позволяющий компилятору не гадать, а знать, что, куда и сколько ходит по переходам.
PGO плох тем, что:
Использует апостерионую информацию. Компилятор не знает ничего о переходах, пока не будет сделано профилирование кода. А это довольно долгий и ответственный процесс.
Предсказания становятся захардкожены. Если в реальном сценарии использования программы статистика переходов будет другой, то получим падение производительности.
Аппаратный предсказатель же позволяет упростить компилятор, упростить систему команд и добавить гибкости в процессе работы программы.
Итаник потонул по многим причинам, но это не значит что заложенные в нем идеи — плохи.Нет — он потонул потому, что его архитектура не имеет смысла. Предполагалось, что компилятор сможет устроить параллелизм на уровне инструкций. Причём по нарастающей: 3 инструкции, 6 инструкций… 66 инструкций за такт… А оказалось — что это невозможно. 2-3 инструкции, которые иногда может вытащить суперскаляр — это предел для прохо параллелящегося алгоритма.
А если алгоритм параллелится хорошо, то он, с вероятностью 99%, хорошо ложится и на GPU — и Итаник снова «не при делах».
Просто неправильно была проведена изначальная оценка: считалось, что Итаниум будет хорошо себя вести на 90% задач, а оказалось — что на 10%, в лучшем случае…
И тем не менее Intel Core жрут до 4 инструкций за такт, и интел обещает сделать до 5 у Sunny Cove, подняв этим производительность. Просто так бы такое не делали.
Кстати, 2-3 за такт это для CISC, RISC это 3-5 для хорошего суперскаляра, а в случае MISC/микрокода до десяти доходит.
Кстати, 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 под одну гребенку.
UPD: Только сейчас дошло, что вы о производительности одного потока с исключительно последовательно выполняемыми командами. В подобном случае и внеочередное исполнение мало поможет, если каждая последующая инструкция зависит от предыдущей.
Для 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 лет назад.
Да — например, у современных DL-ускорителей нужно компилировать (или как они называют — «оптимизировать») код под каждый тип отдельно, а полученный бинарник не работает даже на следующей версии от того же производителя.
А последний знает больше о коде, чем процессор, потому может более вольно менять порядок инструкций.
Не может. А вот 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 инструкций). Не очень быстро, да?
Не может. Бранчи в коде в среднем встречаются каждые 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.
Там спекуляция необучаемая, а Spectre — в чистом виде использование (пере)обученного предиктора для вытягивания инфы из защищенных областей памяти.
Или я ошибаюсь?
Или я ошибаюсь?
Нет, всё верно. Эльбрус использует спекуляцию, но это другая спекуляция. Хотя теоритически взлом не опровергнут.
Конечно, от 0day не убежишь
С учётом того, что Spectre влияет на ARM, POWER, RISC-V — а и вообще на любые процессоры, которые поддерживают спекулятивное исполнение неясно на что предлагается переходить.
По хорошему-то нужно научиться писать так, чтобы программы могли исполняться на сотнях (а в перспективе — и на тысячах) медленных ядер, но… это ж не x86 придётся похоронить, это придётся терабайты уже написанного кода похоронить — кто это может себе позволить?
По хорошему-то нужно научиться писать так, чтобы программы могли исполняться на сотнях (а в перспективе — и на тысячах) медленных ядер, но… это ж не x86 придётся похоронить, это придётся терабайты уже написанного кода похоронить — кто это может себе позволить?
Хм. Ну зачем же систему команд менять? Да даже и спекулятивное выполнение не обязательно выкидывать.
Например, каждой странице назначаем ключ/маску, в результате разные процессы будут видеть память по разному. И потребуется изменить только ОС, причём в сравнительно небольших объёмах.
Например, каждой странице назначаем ключ/маску, в результате разные процессы будут видеть память по разному. И потребуется изменить только ОС, причём в сравнительно небольших объёмах.
Да даже и спекулятивное выполнение не обязательно выкидывать.Чукча — не читатель? Как раз речь в обсуждаемой статье о том, что практически скрыть «следы» спекулятивного исполнения — не реально.
Слишком много в процессоре разных буферов, кешей и прочего, на которые оно может повлиять. И архитектура команд процессора — тут вообще дело 10е.
И потребуется изменить только ОС, причём в сравнительно небольших объёмах.Если бы. Чтобы «следов» не оставалось потребуется при каждом системном вызове все спекуляции и, главное, все буфера, где спекуляции могут «насладиться» сбрасывать. Это радикально изменит весь дизайн ОС. Потому что сделает системные вызовы баснословно дорогими — а это, как бы, полная противоположность тому, что есть сейчас и под что весь существующий софт заточен…
Э-э-э. Если немного изменим процессор. Есть у в них такой модуль, который занимается кодированием и исправлением ошибок ОЗУ, таким образом что бы каждый пользовательский процесс будет читать данные обработанные уникальным ключом/маской, например, на каждую страницу памяти. То спекулятивное исполнение можно оставить ;)
Причём тут вообще ОЗУ? «Следы» остаются не в ОЗУ, а в многочисленных буферах внутри процессора. И либо вы их чистите при переходе в ядро и обратно, либо нет. Если вы их чистите, то «цена» системных вызовов возрастает на пару порядков (то есть замедление не на 10-15%, как современные патчи делают, а в 10-100 раз), а если не чистите — то всё сводится к тому, как именно злоумышленник заставит CPU поместить результат спекулятивного исполнения именно в ту часть процессора, которую вы решили не прочищать.
Может быть сработает простой трюк: выключить вообще всякие спекуляции при исполнении кода ядра — тогда замедление скорости работы ядра будет многократным, но, возможно, терпимым.
Остальное — паллиатив…
Может быть сработает простой трюк: выключить вообще всякие спекуляции при исполнении кода ядра — тогда замедление скорости работы ядра будет многократным, но, возможно, терпимым.
Остальное — паллиатив…
Ещё раз, чистить не обязательно, изменяем процессор так, что каждый процесс ОС видит данные по конкретному физическому адресу разные, везде разные, во всех кэшах, и всё. Процесс, которые что-то выясняет с помощью спекулятивного выполнения, выяснит нечто своё, ну и Бог с ним.
Для чувствительных данных (ключи, пароли), даже сейчас, без аппаратной поддержки, возможна программная защита (данные под маской/ключом, маска/ключ достаточно часто меняется). В принципе, полностью аналогичная обычным методам защиты от утечки по побочным каналам.
Для чувствительных данных (ключи, пароли), даже сейчас, без аппаратной поддержки, возможна программная защита (данные под маской/ключом, маска/ключ достаточно часто меняется). В принципе, полностью аналогичная обычным методам защиты от утечки по побочным каналам.
Ещё раз, чистить не обязательно, изменяем процессор так, что каждый процесс ОС видит данные по конкретному физическому адресу разные, везде разные, во всех кэшах, и всё.Блин. Вот типичное «мыши, станьте ёжиками». Как вы это сделе представляете? Кеш, он, знаете ли, меньше памяти — а значит, в соотвествии с известным приципом разные участки памяти будут мапироваться на одинаковые места в кеше. Но кроме обычных кешей в процессоре есть масса разных других состояний, на которые тоже можно влиять, а так как эти вещи по объёму меньше — то и проблема стоит острее.
Процесс, которые что-то выясняет с помощью спекулятивного выполнения, выяснит нечто своё, ну и Бог с ним.В том-то и дело, что поскольку разные участки памяти с неизбежностью мапятся на одно место в кеше — то он сможет выяснить не «что-то своё», а «что-то про все участки памяти, замапленные в это же место».
Добиться того, чтобы этого не происходило можно только одним способом — выделив каждом процессу своё ядро… но даже этого не хватит! Потому что останется ещё операционная система, которая тоже выполняется на процессоре со спекулятивным исполнением и которую тоже можно использовать для передачи данных.
Вот если сделать так, чтобы операционка выполнялась на процессоре без спекулятивного исполнения и вдобавок к этому, ещё и все процессор выполнялись на разных физических ядрах (или полностью сбрасывать все кеши при переходе от одного процесса к другому, что, фактически, то же самое)… тогда, возможно утечек удастся избежать.
Для чувствительных данных (ключи, пароли), даже сейчас, без аппаратной поддержки, возможна программная защита (данные под маской/ключом, маска/ключ достаточно часто меняется).Очень-очень сложно. Вы знаете как ключ для XBox360 находят? Уникальный, прошитый в процессор, никогда не выдаваемый наружу? Замером скорости функции memcmp. В прошивке, начиная с какой-то версии вместо memcmp используется посимвольное сравениение всех 16 байтов с занесением результата в 16 байн на выходе, потом их все or'ят и только потом сравнивают с нулём. Но это вы всё можете проделать только если на ассемблере пишите, а если у вас оптимизирующий компилятор — то всегда есть шанс, что он поймёт, что вся эта машинерия эквивалентна memcpy и вернёт её взад!
Ну, как, как? Данные из кэшей попадая в процессор модифицируются исходя из TLB и/или регистра состояния данного процесса, а ля кодов хэмминга, уникальным для каждого процесса образом. Таким образом спекулятивное выполнение другого процесса будет отличаться, т.к. для него будут приходить иные данные в процессор.
Но это для халявщиков, которым наплевать на побочные каналы, а при строгой смене масок/ключей, компилятор не может может вмешаться.
… Но это вы всё можете проделать только если на ассемблере пишите, а если у вас оптимизирующий компилятор...А это ничего, что всё прогрессивное человечество уже многие годы как придумало и использует memset_s()/explicit_bzero()/SecureZeroMemory()?
Но это для халявщиков, которым наплевать на побочные каналы, а при строгой смене масок/ключей, компилятор не может может вмешаться.
А это ничего, что всё прогрессивное человечество уже многие годы как придумало и использует memset_s()/explicit_bzero()/SecureZeroMemory()?Ничего. Потому что это решает лишь мааахонькую часть задачи: как прибрать за собой, чтобы следов не осталось. Если вы можете следить за процессом — у вас появляется масса возможностей, которые эти функции не решают. В частности проблему, описанную мною выше — они не решают тоже.
Таким образом спекулятивное выполнение другого процесса будет отличаться, т.к. для него будут приходить иные данные в процессор.То есть, в частности, разделяемые библиотеки перестанут быть разделяемыми? Чуть лучше, чем полный сброс всего, но тут мы упираемся в необходимость хорошо всё рандомизировать. У L1 и без того задержки изрядные.
И по прежнему остаётся возможность использовать ядро для передачи информации…
Но это для халявщиков, которым наплевать на побочные каналы, а при строгой смене масок/ключей, компилятор не может может вмешаться.Кто ему запретит?
То есть, в частности, разделяемые библиотеки перестанут быть разделяемыми?Если ключи/маски по страницам в TLB, то разделяемые страницы разделяемых библиотек останутся разделяемыми, а приватные приватными. Даже копирование-при-записи будет пахать.
И по прежнему остаётся возможность использовать ядро для передачи информации…Это ж вряд ли. Хотя и зависит от организации конкретного ядра.
Кто ему запретит?Как бы когда пишут константы и/или освобождают память, у компилятора ручки свободны. А когда меняют ключи/маски у компилятора соблазна нет, данные реально изменяются, кроме того эти изменения независимо контролируются и потенциальные ошибки компилятора будут обнаружены.
Если ключи/маски по страницам в TLBTLB — один из самых маленьких и медленных кешей. Потому что полностью ассоциативный. Именно потому L1/L2 кеши обычно используют логический, а не физический адрес.
Хм. Не скажу за все процессоры, но конкретно у x86, L1D и далее физически адресуемые кэш. Иначе их протокол синхронизации кэш (инвалидации при записи на других ядрах/прцессорах/устройствах) работать не будет.
Вот кэш МОП, тот да, виртуализирован, но кэш инструкций в контексте Spectre рассматривать странно.
P.S. Впрочем, сделать L1D с виртуальными адресами, может оказаться неплохой идеей борьбы со Spectre (зачатком идеи).
Вот кэш МОП, тот да, виртуализирован, но кэш инструкций в контексте Spectre рассматривать странно.
P.S. Впрочем, сделать L1D с виртуальными адресами, может оказаться неплохой идеей борьбы со Spectre (зачатком идеи).
Вот если сделать так, чтобы операционка выполнялась на процессоре без спекулятивного исполнения и вдобавок к этому, ещё и все процессор выполнялись на разных физических ядрах (или полностью сбрасывать все кеши при переходе от одного процесса к другому, что, фактически, то же самое)
Достаточно выделять на процесс свой участок кэша, по сути так же, как выделяется память. Возможно, даже не физический участок кэша, а каким-то образом виртуализованный.
Железо потребуется заменить, но архитектура, система команд лишь немного расширится, а может и останется прежней.
UFO just landed and posted this here
Уязвима не архитектура (набор инструкций и регистров), а многие реализации — т.е. микроархитектура. В случае с 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/
В наше время всё и не нужно переписывать. В первую очередь в этом будут заинтересованны военные и бизнес. Сделают РоС для серверного железа, в век микросервисов критические части системы переведут на новое железо. Наверняка напишут JVM и быстро напишут что-то nginx подобное (сколько там строк кода? Пара десятков тысяч?). Всякие молодые языки и так плодятся по 3 штуки в год, гугол быстро подсуетится. Лет через 10-15 всё серверное ПО будет работать на этой архитектуре, а там и до персоналок дойдёт.
Проблемы архитектуры х86, они не в архитектуре х86, а в экономике. Эта самая х86 потому и победила более эффективные и удачные процессорные архитектуры за счет того, что тянула с собой legacy. Единственная альтернатива, которая теперь может с ней потягаться, ARM, стала настолько популярной за счёт того, что поселилась в нише встраиваемых и энергоэффективных устройств, на которую х86 практически не посягали, и вдруг эта ниша резко выросла с бумом гаджетов.
А фактор легаси работает до сих пор. Программы — они ведь более ценные, чем железяки.
Ну и второй немаловажный момент, на самом деле очень мало шансов, что новая хорошая архитектура окажется на самом деле хорошей, а не как обычно — с кучей недостатков и проблем, которые выявляются уже в процессе запуска, и на которые в старой архитектуре были костыли/заплатки.
А фактор легаси работает до сих пор. Программы — они ведь более ценные, чем железяки.
Ну и второй немаловажный момент, на самом деле очень мало шансов, что новая хорошая архитектура окажется на самом деле хорошей, а не как обычно — с кучей недостатков и проблем, которые выявляются уже в процессе запуска, и на которые в старой архитектуре были костыли/заплатки.
Всё верно, но ведь ничего не делать со Spectre и оставить всё как есть тоже нельзя.
Желание все выбросить и написать всё правильно выдает в комментаторе юношеский максимализм.
С другой стороны, сегодня большинство серверов состоят из полностью опенсорсного кода (за минусом фирмвари), а клиенты всё более сводятся к браузеру. Всё это скомпилировать из исходников в другую архитектуру — вполне решаемая задача. x86 сегодня выигрывает скорее именно в стандартизированной фирмвари, наличии виртуализации и хороших периферийных интерфейсах. Благодаря этому один дистрибутив ОС разных вендоров без изменений заводится на разных материнках, и автоматом подхватывает всё железо, чего ARM-у и не снилось.
Вы вообще статью-то читали? Там же ключевой момент аж даже жирным выделены! Я процитирую:
1. Процессоры без спекулятивного исполнения, где 100500 уровней индирекции, порождённые архитектурными астронавтами, дико тормозят
2. Процессоры со спекулятивным исполнением, где избавиться от Spectre практически невозможно
Причём тут вообще x86? POWER и ARM точно так же подвержены Spectre, как и x86…
все процессоры со спекулятивным выполнением всегда будут подвержены различным атакам боковых каналов, несмотря на методы частичной защиты, которое могут быть реализованы в будущем.Вы можете хоть уперекомпилироваться, но это ничего это не изменит, так как все процессоры делятся на два непересекающихся класса:
1. Процессоры без спекулятивного исполнения, где 100500 уровней индирекции, порождённые архитектурными астронавтами, дико тормозят
2. Процессоры со спекулятивным исполнением, где избавиться от Spectre практически невозможно
Причём тут вообще x86? POWER и ARM точно так же подвержены Spectre, как и x86…
Если такое и будут делать то ориентироваться будут на игровые консоли и серверы, рядовой пользователь вряд ли слезет с x86.
Похоронить — надо. Но проблема в самом спекулятивном выполнении, от которого отказаться попросту нельзя.
Хороший момент чтобы Apple перешла на свои процессоры на mac, как это уже сделала на iOS :)
А ничего, что их процессор для iOS так же подвержен Spectre, как и все остальные?
С чего вдруг? Он базируется на RISC, а в статья явно сказано что они не подвержены этой проблеме.
VLIW не подвержены, RISC и CISC подвержены если используют внеочередное исполнение инструкций и предсказатель переходов.
Тогда вопрос к автору статьи а не ко мне. Было явно сказано что RISC не подверженып пробелмы спектра.
А вообще я думаю что Apple как производитель процессоров со своей архитектурой это быстро исправит. Потому всё остаётся как я и говорил.
Посмотрим. Только время покажет :)
А вообще я думаю что Apple как производитель процессоров со своей архитектурой это быстро исправит. Потому всё остаётся как я и говорил.
Посмотрим. Только время покажет :)
Там вообще много чего было сказано. В частности была ещё и ссылка на статью с говорящим названием: Патч против Spectre в iOS 11.2.2 замедляет устройства на 50%? (ответ, кстати, отрицательный: патч на 50% iOS не замедляет)… Так что…
Сама же идея что Apple может исправить фундаментальную проблему, потому что у них «своя архитектура», а Intel — не может, потому что… «ну тупыыыые» — тут неясно смеяться или плакать…
Сама же идея что Apple может исправить фундаментальную проблему, потому что у них «своя архитектура», а Intel — не может, потому что… «ну тупыыыые» — тут неясно смеяться или плакать…
Нет, не потому.
Apple выпускает устройства полностью прорабатывая как железо так и софт.
И в случае изменения архитектуры проца просто подгонит софт и ничего при этом не сломается.
Intel же выпускает только процессоры, и в случае изменения архитектуры процессора возникнет вопрос с тем что внезапно перестанет работать какой-то софт, нужно будет куча исправлений.
Вспомните как Apple перешла с PPC на Intel. Они просто взяли и сказали — всё уже готово, забирайте. И у людей весь нужный софт работал и сразу был под рукой. А это полная смена архитектуры, пересборка всей ОС и модулей.
Я также уверен что Apple скоро переведёт маки на свой проц. Возможно на комбинацию в паре с Intel процом для совместимости со старой архитектурой или с каким-нибудь аппаратным эмулятором этой архитектуры, кто знает.
В iOS ещё есть другой момент — это закрытая ОС на которую невозможно поставить софт вредящий системе если пользователь сам сознательно себя не подвергает опастности. В случае с Windows это не так, увы.
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, как и любой из известных VLIW, мог эффективно работать только при условии разумно предсказанных длительностей всех операций в группе. При разнице времени доступа L1::DRAM около 100 раз это нереально.
IA64 проектировался тогда же, когда Intel обжигалась об Rambus. Поэтому они и смогли вляпаться в такую авантюру.
IA64 проектировался тогда же, когда Intel обжигалась об Rambus. Поэтому они и смогли вляпаться в такую авантюру.
С какой скоростью будет работать эмуляция?
Помню как первые модели 64-битных процессоров от Intell провалились из-за тормозной эмуляции, и что 64-битные процессоры от AMD стали успешными благодаря аппаратной поддержке x86.
И разве на x86 была эта проблема?
Помню как первые модели 64-битных процессоров от Intell провалились из-за тормозной эмуляции, и что 64-битные процессоры от AMD стали успешными благодаря аппаратной поддержке x86.
И разве на x86 была эта проблема?
Я вот только не понимаю, почему на это исследование ушел целый год. Все было понятно и так. И эти же самые исследователи говорили, что нужно готовиться к целому классу новых уязвимостей. Короче нужно осознать и принять, что в ближайшее время будет все больше подобных атак и заплаток жертвующих производительностью.
ЗЫ В какой-то мере, это может даже помочь. Уж больно современный софт прожорливым стал.
ЗЫ В какой-то мере, это может даже помочь. Уж больно современный софт прожорливым стал.
в ближайшее время будет все больше подобных атакА эти «атаки» вообще были?
Даже если и нет — то будут. Использовать эти уязвимости не очень просто, и потребуется время и ресурсы на то, чтобы создать эффективные эксплойты. Если сейчас атаки традиционным способом (через уязвимости софта) дешевле, то в эксплойт для Spectre могли особо не вкладываться. Но вот после таких новостей, когда становится понятно, что Spectre вряд ли когда-либо закроют, создание "вечного" эксплойта, который будет работать всегда и везде, и который невозможно заблокировать — вполне может стать достаточно привлекательным, чтобы вложить достаточно средств в его разработку.
Перефразирую. "… будет все больше уязвимостей, использующих данный вектор атаки,..."
А по поводу были или нет. Думаю, что в исследовательских целях был сделан не один дамп. На мой взгляд, проблема сейчас в том, что атакующему нужно знать, что искать в полученном дампе, и это сложнее чем осадить дамп памяти в каком-то кеше.
А по поводу были или нет. Думаю, что в исследовательских целях был сделан не один дамп. На мой взгляд, проблема сейчас в том, что атакующему нужно знать, что искать в полученном дампе, и это сложнее чем осадить дамп памяти в каком-то кеше.
снижение точности таймераКак бы Intel изначально всё так и задумал, и в x86 изначально был бит отключения RDTSC для непривилегированных процессов. Конечно, его можно усложнить, скрестить с RDRAND.
Но, сдаётся мне, если сейчас базу RDTSC случайно изменять с частотой HZ (_SC_CLK_TCK), естественно, корректируя переменную смещения для системных вызовов clock_gettime()/gettimeofday(). То, если всё сделать разумно, Spectre не пройдёт ;)
Уже проводились исследования — можно вообще без RDTSC. Просто считать количество итераций цикла. Менее удобно и надёжно — но работает. Уж очень времена доступа к тому, что есть в кеше и к тому, чего там нет отличаются — примерно на два порядка (не двоичных, нет: L1 — это 4-5-6 тактов, оперативка — это 400-500-600 тактов)
UFO just landed and posted this here
UFO just landed and posted this here
Утопия. Сложность перекладывается с софта на железо, которое всегда и везде конкурировало намного сильнее, подвержено физическому износу и браку.
Кодите тоже без фреймворков, чтобы без примитивов?
Кодите тоже без фреймворков, чтобы без примитивов?
UFO just landed and posted this here
Не холивара ради. Я программирую на том самом, седьмом ещё Дельфи. С детства почти, очень профессионально, логику с интерфейсом не мешаю. Сегодня работаю, а не давным-давно работал. И мне таки неудобно. Не хватает современных, классических уже примитивов. Огромное количество нелепый телодвижений нужно, чтобы сделать, к примеру, аналог лямбда-функции. Или сделать ORM, (писал для последнего проекта) — неудобно, нету аннотаций. Без дженериков (нету их) — боль. А Вы говорите, примитивы не менялись… И даже так, "в режиме эмуляции современности", получаются системы намного более сложные в пересчёте на час рабочего времени и куда как более гибкие, чем тогда.
Бэйсик — особая история. Тот, с которого я начинал программировать, имел только глобальные переменные. Только глобальные, Карл! Переменные на стеке? Рекурсия? Не слышали… Шестнадцать лет назад щупал vb, там стало намного лучше, но классы наследовать нельзя было. Абстракция, обобщения? Тьфу на вас ещё раз, обойдётесь!
То, что я вспоминаю старое время с теплотой не говорит о том, что "сидеть под голым досом и не стыдиться" было лучше. Может, нам-тогдашним, молодым, горячим, наивным и было в кайф, я не спорю. Было, мне так точно было. Но я вырос. Я решаю насного более сложные задачи, и делаю это кратно быстрее. Я думаю об архитектуре, о трудоёмкости доработок, о читаемости кода. И в этом намного больше удовольствия! Я могу больше. Свой опыт, чужой опыт. И то, и другое часто выражено в примитивах, абстракциях. Новых примитивах, новых абстракциях. И они реально создают моё качество работы и её эффективность .
А старый, "добрый" Дельфи — я его конечно хорошо умею и очень ему благодарен, но приходится таки время от времени запускать Идею и поднимать себе настроение Джавой. Кайф, честно...
Должна быть одна тысяча строк кода а остальное должно быть реализовано аппаратно
intel на это и напоролась, обойти аппаратную фичу не может полностью
Не должно быть миллионов строк кода. Должна быть одна тысяча строк кода а остальное должно быть реализовано аппаратно. В FPGA или ещё как — не суть важно.Посмотрите на историю изменений этих строк — сколько раз там находились ошибки, что-то исправлялось и доделывалось.
А теперь представьте что изменение это не програмный патч, а необходимость переделывать архитектуру на низком уровне. Насколько сложней будет внедрять патчи?
UFO just landed and posted this here
Давайте посмотрим с другой стороны.
Сколько времени потребуется программисту чтобы написать аналитическую систему комплексной стат.обработки с чтением\сохранением разных форматов данных и построением графиков\диаграмм на Бейсике 80-х годов и на современном Питоне с библиотеками?
Задачи принципиально усложнились.
Когда PHP начал распространятся 20 лет назад сайты состояли из нескольких шаблонов и нескольких форм и всё, структура страниц была проще, ни о какой динамической подгрузке, адаптации под мобильные, кучи кастомизации речи не шло.
Сколько времени потребуется программисту чтобы написать аналитическую систему комплексной стат.обработки с чтением\сохранением разных форматов данных и построением графиков\диаграмм на Бейсике 80-х годов и на современном Питоне с библиотеками?
Задачи принципиально усложнились.
Когда PHP начал распространятся 20 лет назад сайты состояли из нескольких шаблонов и нескольких форм и всё, структура страниц была проще, ни о какой динамической подгрузке, адаптации под мобильные, кучи кастомизации речи не шло.
Задачи принципиально усложнились.
Смотря с каким периодом сравнивать. Если брать совсем уж зарождение отрасли, то да, принципиально усложнились. Если брать чуть позже, например, уже вторую половину 1990-х, то там не было некоторых современных отраслей IT, например, BigData и Machine Learning, но на 90% решаемые задачи вполне себе соответствовали нынешним, естественно, с поправкой на окружение тех лет. Т.е. вместо веба клиент-серверные и распределенные десктопные приложения, вместо шустрых интернетов локальные сети предприятия и модемы.
Инструментарий разработки десктопных приложений в те годы был не хуже, а то и лучше, чем сейчас его аналоги для веб-приложений. При этом скорость реализации функционала, я не ошибусь, если скажу, что была заметно выше.
Инструментарий разработки десктопных приложений в те годы был не хуже, а то и лучше, чем сейчас его аналоги для веб-приложений.Десктопное приложение тогда обычно разрабатывалось под конкретную операционную систему и разрешение экрана, а веб-приложение должно сейчас работать и на планшете и на телефоне и на десктопе в разных браузерах и разрешениях, к тому же права такого приложения на действия в системе существенно ограничены из соображений безопасности.
Так что учитывая кросс-платформенную поддержку и отзывчивость дизайна, сложность системы в целом тоже существенно увеличилась.
Да не сильно большая и разница, если честно. Тогда была другая особенность дизайна приложений — поддержка произвольного размера окна. Понятно, что не все этим заморачивались, но в целом для профессиональной, а не наколенной разработки надо было точно так же учитывать, что размер окна вашего приложения может быть любой, и соответствующим образом подстраивать интерфейс. А с браузерами наоборот, времена, когда надо было держать в уме особенности IE, Netscape и Opera, тоже позади. 80% — Blink, 20% — практически полностью совместимые с ним WebKit, Edge, Mozilla. Причем отличия на уровне «добавить ещё одну строчку в стиль, чтобы в Сафари убрать лишнее свечение дропдаунов в фокусе».
Сколько нужно времени чтобы просто получить промпт питона?Да примерно столько же.
Да, с какой-нибудь IDE всё будет посложнее, но она и возможности даёт несопоставимые с тем бейсиком.
Я один вижу здесь взаимоисключающие параграфы?
Какая разница, где у вас будут ошибки, если ошибки неизбежны?
Сейчас миллиарды транзисторов невозможно полностью контролировать
. Не должно быть миллионов строк кода. Должна быть одна тысяча строк кода а остальное должно быть реализовано аппаратно.
Какая разница, где у вас будут ошибки, если ошибки неизбежны?
Не должно быть миллионов строк кода. Должна быть одна тысяча строк кода а остальное должно быть реализовано аппаратно.А аппаратный код собирают по весне с чайных деревьев?
Должна быть одна тысяча строк кода а остальное должно быть реализовано аппаратно. В FPGA или ещё как — не суть важно.Вы же в курсе, что микросхемы проектируются посредством написания кода на языке Verilog, да? )
UFO just landed and posted this here
UFO just landed and posted this here
Наиболее вероятен совсем другой подход. Приведу аналогию. Есть государство и преступники, в государстве нашли уязвимость которая позволяет преступникам совершать зло. Все комментаторы выше предлагают изменить государство таким образом чтобы в нём не было зла изначально, что неверотяно дорого и сложно, утопично я бы сказал. Это правильный подход с логической точки зрения, однако он практически невыполним в текущих условиях. Более практичным и дешёвым подходом будет охота на преступников.
Таким образом имеем проверку исходного кода, поиск, выявление и преследование тех, кто уязвимостями пользуется.
Для тех кто собирается комментировать про спецслужбы — в их арсенале наверняка есть как более продвинутые так и более архаичные методы получения информации, и да, то что считается незаконным для обычных граждан может быть позволено и оправдано для использованияя спецслужбами, будь то насилие, кража информации т.д. в «высших» целях. Вопрос о преследованиях политических оппонентов и всего с этим связанного находится скорее в плоскости морали и его я обсуждать не намерен.
Таким образом имеем проверку исходного кода, поиск, выявление и преследование тех, кто уязвимостями пользуется.
Для тех кто собирается комментировать про спецслужбы — в их арсенале наверняка есть как более продвинутые так и более архаичные методы получения информации, и да, то что считается незаконным для обычных граждан может быть позволено и оправдано для использованияя спецслужбами, будь то насилие, кража информации т.д. в «высших» целях. Вопрос о преследованиях политических оппонентов и всего с этим связанного находится скорее в плоскости морали и его я обсуждать не намерен.
Более практичным и дешёвым подходом будет охота на преступников.И государства за тысячелетия охоты за преступниками так и не смогли полностью их искоренить.
Это по-сути задача «снаряда и брони». Чем сильней становится защита, тем изощренней находятся способы ее обойти.
Вот именно, никто и ничто не совершенно, я написал тоже самое про предлагаемую утопичную архитектуру. Однако в некоторых государствах удалось добиться очень низкой преступности, благодаря нормальной работе правоохранительных органов.
Мой комментарий не о нахождении новых уязвимостей, он об использовании уязвимостей как таковых, это ведь осознанный выбор.
Мой комментарий не о нахождении новых уязвимостей, он об использовании уязвимостей как таковых, это ведь осознанный выбор.
По-адекватному стоило бы снизить цены на текущие и прошлые поколения процессоров Интел. И разрабатывать новые.
По сути продают процессоры с вечной дырой в защите.
Не зря по слухам Эпл уходит на RISC
А можно просто выключить спекулятивное выполнение? Для многих задач, если производительность упадёт раза в два, а не в тысячу, но при этом такие атаки будут исключены, то и ладно.
А если производительность проседает сильно, нельзя ли просто ввести команды выключения-включения спекулятивного выполнения, чтоб код, который отвечает за что-то критичное по безопасности, отключал спекулятивное выполнение, а потом его снова восстанавливал?
А если производительность проседает сильно, нельзя ли просто ввести команды выключения-включения спекулятивного выполнения, чтоб код, который отвечает за что-то критичное по безопасности, отключал спекулятивное выполнение, а потом его снова восстанавливал?
Скорее, имеет смысл добавить новый бит «не использовать для спекулятивного выполнения» к флагам страниц памяти, чтобы защищать данные. Сейчас же есть только бит — «не кэшировать».
А можно просто выключить спекулятивное выполнение? Для многих задач, если производительность упадёт раза в два, а не в тысячу, но при этом такие атаки будут исключены, то и ладно.Там разница раз в десять будет. Современные процессоры делают очень много разных спекуляций на разных уровнях. Если из выключить все — будет очень больно.
Божечки ж ты мой.
Тезис N1: Spectre (S) и Meltdown (M) являются прямым следствием роста сложности реализаций процессоров. Современный ЦПУ обладает сумасшедшим уровнем сложности. В частности, SM-уязвимость возникает на стыке казалось бы независимых компонентов: предсказание ветвлений, спекулятивное выполнение, кэширование, механизмы организации безопасности, механизмы организации адресных пространств. Их можно закрыть аппаратно. Но! Очень сложно гарантировать отсутствие подобных уязвимостей при сохранении текущего уровня сложности ЦПУ.
Тезис N2: Уязвимости типа SM можно закрыть программно на уровне ОС. SM дает возможность читать из той части адресного пространтства текущего процесса, которая принадлежит ядру. Соответственно, нужно сделать так, чтобы в этой части адресного пространтства не было критически важной информации. Соответственно:
Вариант а) Микроядро в основе системы. В истинных микроядрах в пространстве ядра нет ничего интересного для чтения вредоносом. Все что интересно, находится в адресных пространствах ДРУГИХ процессов, куда нужно сначала переключится. Так что туда с помощью SM не залезть
Вариант б) Для Linux-подобных систем. Ядро выгружается в свое отдельное виртуальное адресное пространство (свой процесс). В пользовательских процессах остается только заглушка, которая по системному вызову (прерыванию) производит переход в виртуальное адресное пространство ядра и передает туда же управление. Опять же, прощай SM.
Так что закрыть SM чисто программно можно на уровне ОС. НО! Это не дешево! Потери производительности будут значительными! Стоимость холосного системного вызова выростет как минимум в 5-10 раз. И на это еще наложится трэшшинг кэша и TLB. Так что совокупные потери производительности могут легко дойти до величин в районе в два раза.
Тезис N1: Spectre (S) и Meltdown (M) являются прямым следствием роста сложности реализаций процессоров. Современный ЦПУ обладает сумасшедшим уровнем сложности. В частности, SM-уязвимость возникает на стыке казалось бы независимых компонентов: предсказание ветвлений, спекулятивное выполнение, кэширование, механизмы организации безопасности, механизмы организации адресных пространств. Их можно закрыть аппаратно. Но! Очень сложно гарантировать отсутствие подобных уязвимостей при сохранении текущего уровня сложности ЦПУ.
Тезис N2: Уязвимости типа SM можно закрыть программно на уровне ОС. SM дает возможность читать из той части адресного пространтства текущего процесса, которая принадлежит ядру. Соответственно, нужно сделать так, чтобы в этой части адресного пространтства не было критически важной информации. Соответственно:
Вариант а) Микроядро в основе системы. В истинных микроядрах в пространстве ядра нет ничего интересного для чтения вредоносом. Все что интересно, находится в адресных пространствах ДРУГИХ процессов, куда нужно сначала переключится. Так что туда с помощью SM не залезть
Вариант б) Для Linux-подобных систем. Ядро выгружается в свое отдельное виртуальное адресное пространство (свой процесс). В пользовательских процессах остается только заглушка, которая по системному вызову (прерыванию) производит переход в виртуальное адресное пространство ядра и передает туда же управление. Опять же, прощай SM.
Так что закрыть SM чисто программно можно на уровне ОС. НО! Это не дешево! Потери производительности будут значительными! Стоимость холосного системного вызова выростет как минимум в 5-10 раз. И на это еще наложится трэшшинг кэша и TLB. Так что совокупные потери производительности могут легко дойти до величин в районе в два раза.
кроме RISC и российского «Эльбруса»
1. ARM — RISC и он частично подвержен Spectre
2. У Эльбруса нет предсказателя переходов и он действительно не подвержен большому классу уязвимостей. Тем не менее теоритически он может быть подержен сходим уязвимостям.
Sign up to leave a comment.
Исследователи из Google: для защиты от Spectre требуется изменение архитектуры процессоров, программные патчи не помогут