Плюсую. Результаты RTX 3080 и 3090 были-бы очень органичны в табличках (но включая и 24 Гб), их прям хочется увидеть рядом. Причем ведь достаточно логичный подход - локально поэкспериментировать на "кошечках", а сетку для production тренировать на арендованном DGX A100.
Может показаться, что я специально провоцирую Вас выставлять напоказ некомпетентность и "умение" притягивать аргументы за уши (примерно как в вашем крайнем ответе).
Но на самом деле, я даю пояснение к своей позиции/тезисам и отвечаю на те вопросы, которые, как мне кажется, этого заслуживают.
Эта индустрия существенно меньше «прочих индустрий»
Относительно небольшой размер индустрии безопасности == Относительно небольшое количество пожарных.
поэтому ее потребности разработчики удовлетворяют не в первую очередь.
Снижение рисков эксплуатации уязвимостей являются потребностью потребителей/пользователей, а не "разработчиков" в индустрии ИБ (для ИБ как-раз наоборот, чем больше потенциальных дыр/угроз, тем больше бюджет).
...вы сами описали несколько способов обхода проблемы,
Не обхода проблемы, а потенциального/гипотетического обхода защиты при наличии других ошибок/недостатков в ПО и/или железе.
Если же под одним из "способов обхода проблемы" подразумеваете смену ABI, то это примерно равнозначно повторному портированию ПО. Соответственно, это должно быть сделано до начала широкого использования архитектуры, либо станет невозможным как в случае с x86.
а значит вам не критично, чтобы эти проблемы решала за вас система команд процессора.
Не "нам", а для безопасности данных/процессов/пользователей.
Не "не критично", а существенно снижает риски, но не даёт полной гарантии, ибо её нельзя дать из-за ненулевой вероятности реализации сложной атаки с участием других ошибок/уязвимостей/недостатков.
Не "решала за нас проблемы", а чтобы система команд не имела очевидных брешей в безопасности, которые в случае с RISC-V заботливо сохранены.
---
В целом похоже на ситуацию с прививкам. Озвучиваем "так небезопасно, нужна <прививка>", а в ответ весь набор аргументов антиваксеров.
... индустрия в целом смотрит на это несколько иначе...
Индустрия занимающаяся обеспечением безопасности, либо вынужденная ей заниматься, имеет мнение отличное от прочих «индустрий». https://www.securitylab.ru/news/519772.php и т.д. и т.п.
Давайте я спрошу простую вещь - чем 2 стэка лучше решения, когда у нас весь код в исполняемом файле замаплен с аттрибутами rx, а стэк выделен как rw ?
Если стек адресов возврата отделен от стека используемого для передачи параметров и размещения локальных данных функции (автоматических переменных в терминах С), то ошибка приводящая к записи за пределы локального буфера не позволит переписать адрес возврата (если только не переписать всю память между стеками и т.п.). Аналогично нет возможности непосредственно подготовить в стека адресов возврата массив адресов для ROP.
При использовании ROP код в памяти не переписывается (может быть только для чтения). Инструкции с адресов стека не выполняются (NX не имеет значения). ALSR может быть не эффективен, если через "читающее переполнение" удаётся прочитать кадры стека до генерации ROP-инъекции и т.д. и т.п.
Но это не даёт гарантии, ибо (в общем случае) возможны более сложные многоэтапные атаки, начинающиеся с перезаписи указателей на стеке и/или других данных в других места. Тем не менее, разделение стеков существенно (в разы) затрудняет доведение атак до финала и снижает риски эксплуатации уязвимостей.
Коллега посоветовал уточнить/пояснить "пару моментов" в моём обосновании небезопасности/нелюбви к RISC-V и фразе «бережно сохранено всё необходимое для ROP». Не думаю, что этот комментарий прочитает больше чем несколько человек, но считаю написать стоит.
Суть в том, что в RISC-ах в явном виде в аппаратуре нет стека "как на x86". Стек специфицируется/реализуется на уровне ABI посредством назначения ролей регистрам и соглашения о вызове функций, а инструкции push, pop, call и ret отсутствуют на уровне аппаратуры в явном виде и являются макросами и/или псевдоиструкциями. Программное обеспечение может реализовать поверх ISA один, два или сколько угодно стеков. Поэтому предъявлять претензии к набору команд RISC-V по поводу одного стека необоснованно — вроде-бы всё верно, но...
Собственно говоря, программно реализовать два стека, т.е. отделить данные (и потенциально уязвимые буфера на стеке) от адресов возврата, можно на всех архитектурах (имеющих косвенную адресацию), включая x86, ARM, MIPS и т.д. Принципиально ничего невыполнимого нет (но будут нюансы), разница только в объеме накладных расходах, трудоёмкости и (не)привязке к возможностям и/или контролю аппаратуры.
Если возможно программно реализовать два стека на чуть менее чем любой архитектуре ЦПУ и это, прежде всего, связано со сменой ABI, то «количество стеков» — это атрибут ABI? Либо ABI (может именно этот аспект) является какой-то значимой частью архитектуры как экосистемы?
Говоря что у RISC-V один стек, я знаю о возможности его разделить сугубо программно сменой ABI. Однако, если смотреть на «экосистему архитектуры» RISC-V:
представлен только «одностековый» вариант ABI и всей экосистемы;
явно определено reg(sp) == reg(x2), push/pop в/из RAS для jalr;
нет упоминания о втором sp для передачи большого кол-ва аргументов и хранения локальных данных, отдельно от RAS;
для разделения стеков требуется специфицировать ABI, поправить компилятор(ы)/toolchain и доперепортировать софт.
Поэтому я критикую RISC-V как одно-стековую архитектуру подверженную ROP: не предусмотрено какое-либо разрешение/запрещения переходов/возвратов к командам, нет само-синхронизации кодирования команд переменной длины.
С другой стороны, на x86 тоже можно сменить ABI, разделить стек, многократно снизив этим риск эксплуатации уязвимостей. Подобное разделение приведёт к некоторой потери плотности кода, в основном из-за заметы push на mov [reg + offset] при подготовке/передачи аргументов. Но для рынка это давно табу из-за слома совместимости и необходимости допиливать тонны софта.
AMD разрабатывали AMD64 как расширение ISA более 20 лет назад, думая о time-to-market и минимизации непохожести с x86_32. Ожидаемо, что тогда не думали про два стека. Но с RISC-V принципиально иначе: потеря эффективности минимальная (занимаем один регистр), а слома ABI вообще могло не быть.
Поэтому мне не ясны (не очевидны) причины, по которым для RISC-V специфицировано только «одностековое» ABI и «бережно сохранено всё необходимое для ROP и эксплуатации традиционных ошибок выхода за пределы буфера на стеке».
Вы говорите об «опциональной» безопасности конкретных реализаций ядер. В частности, например, о выключении/блокировании спекулятивной загрузки для предотвращения Spectre/Meltdown. Понятно что «так можно делать», в том числе решать/выбирать для каждого конкретного ядра (модели ЦПУ).
А я писал про проблемы ISA как таковой — сохранено всё необходимое для ROP и эксплуатации записи за границы буфера. Здесь нельзя реализовать каких-либо эффективных мер/механизмов без нарушения бинарной совместимости с ISA (Intel делал несколько подходов).
Хотя, теоретически, можно «форкнуть» и сделать RISC-6, поправив Spectre и остальные недопеределки (вот, если-бы Yando взялось, то я бы помог...).
«болген» - это, конечно, просто одна из опечаток (привык к высокому разрешению и мелкому шрифту, а зрение уже подводит - не замечаю).
Что касается тона и термина "Болден-RISC", то в этой шутке есть доля правды. Конечно, с одной стороны, хорошо что есть открытые ISA, IP и целые ядра. Но нас ждет зоопарк ядер не меньший чем зоопарк дистрибутивов Linux, и проблема зависимостей (привет nmp), как по IP, так и по программному коду.
Открытость ISA, расширяемость и доступность готовых IP, приводит к появлению массы как стартапов, так и отделов разработки собственных ЦПУ со "стартаперским духом" — когда важно быстро-быстро показать первый результат, а какие-то неудобные вопросы/проблемы замести под ковер с обещанием "потом всё порешаем, когда доплывём".
Среди таких вопросов — небезопасность RISC-V. Конечно RISC-V нельзя назвать более дырявым чем другие ISA в своих сегментах. Но для меня несколько странно/неожиданно, что в RISC-V бережно сохранено всё необходимо для эксплуатации всех традиционных ошибок/дыр.
Да, пожалуй, у меня есть определенное "профессиональное искажение". Тем не менее, свободно-бесплатная раздача ISA и ядер с явными (бережно сохраненными) проблемами с безопасностью — всё-таки начинает выглядеть как сыр в мышеловке.
При этом я (пока) не встречал человека на позиции ЛПР, который-бы понимал все сложности и проблемы связанные с управлениями этими зависимостями, и уже планировал бизнес-процессы и жизненный цикл устройств/продукции с учетом необходимости отслеживания ошибок/проблем/уязвимостей и (соответственно) необходимости обновлений и замены/отзыва проблемных устройств.
Так вот, совокупность всего вышеописанного, вместе с создаваемым хайпом, позволяю себе называть "Болден-RISC".
(думаю стоит написать статью с освещением всех этих вопросов).
Вы не владеете темой, но продолжаете изображать специалиста и гнуть свою линию, неся при этом ерунду.
1. Эксплуатация Spectre/Meltdown требует локального доступа. А на Эльбрусах дополнительно еще и возможности конструировать нативный исполнимый код (в памяти или в файлах), так как JIT-ов примерно нет.
2. Уязвимости связанные с выходом за пределы буфера и использованием ROP могут эксплуатировать удаленно достаточно часто. Но на Эльбрусах вероятность их эксплуатации кардинально ниже из-за двойного стека. Причем это без учета возможности использования защиты «тегами», которая может быть использована только в процессах подверженных рискам атаки.
3. Соответственно, на Эльбусах относительно легко защититься от Spectre/Meltdown просто адекватным системным администрированием (например, хотя-бы убрать компиляторы и запретить взводить eXecute бит у файлов). Вероятность же удаленной эксплуатации Spectre/Meltdown через ROP стремиться к нулю. Причем всё это без учета противодействия Spectre/Meltdown со стороны ядра ОС.
Поэтому, я действительно вижу отдельные недостатки, но не вижу принципиальных проблем с безопасностью Эльбрусов, особенно в сравнении с x86, ARM, MIPS и болден-RISC (aka RISC-V).
Хм, эка Вы повернули ;) Конечно можете тут крутить/вертеть слова как хотите, в том числе и мои осторожно-аккуратные формулировки о (не)эксплуатируемости Specte-подобных проблем на Эльбрусах (требуется ждать завершения работ и раскрытия информации).
От советов перечитывать и дальше получать "квалифицированные" ответы я вежливо откажусь, и подведу черту чтобы не тратить время:
1. В Эльбруса со Spectre не хуже чем в любых других процессорах со спекулятивной загрузкой. А в следующей версии архитектуры этих проблем не будет. Тогда как намерения Intel/AMD по устранению не декларированы, а в участники RISC-V (видимо) вообще не считают это проблемой.
2. В Эльбрусе отдельный стек для адресов возврата, плюс возможность использовать теги и расширенные указатели для дополнительной защиты. Поэтому риски эксплуатации ROP, включая ошибки записи за пределы буфера, double-free и use-after-free кардинально ниже.
3. У RISC-V как ISA нет значимых технических/технологических преимуществ при переходе в сегмент высокопроизводительных ЦПУ.
Ну я вам, как выбравшему тест, задал несколько вопросов. Получил на них ответы? Нет. Это достаточно, на мой взгляд, очерчивает уровень в первую очередь вашего понимания что вы делаете. А за сим дальнейший разговор теряет смысл. Разберетесь в вопросе достаточно чтобы обосновано дискутировать - можно будет продолжить.
Хм, не увидел вопросов на которые не было-бы ответов и/или стоило-бы отвечать отдельно или еще раз. Но давайте пройдемся вместе:
Почему 1.5 ГГц?
Как указал в самом начале - чтобы выровнять частоту с Эльбрус-8СВ. Но, видимо, стоило подробнее пояснить, что базовая частота Xeon 5317 равна 3000 МГц и удобна тем, что ровно вдвое больше частоты Эльбрус-8СВ. Соответственно, 1500 было выбрано как удобно/равное значение после неудачи с переключением Xeon на его родные 3 ГГц.
Наверно стоило как-то обозначить, что сравнивается эффективная/наблюдаемая "скорость архитектур", как если-бы они (были сделаны по одному техпроцессу и) работали на одинаковой частоте. Но вроде-бы это и так понятно из контекста производимых действий и начала текста.
Почему 42 тысячи это хорошее число?
Собственно, я же уже отвечал "этот бенчмарк - утилитарный инструмент для проверки и оптимизации собственных сортировок (в частности для libmdbx), и 42 тысячи там именно потому-что 42". Проще говоря, такой размер сортируемого массива просто подходит (вроде-бы очевидно?) для сравнения скорости сортировок между собой и просто остался в исходниках с его предыдущего использования.
Еще у вас были упоминания про управление частотой в тестах на энерго-эффективность - но я сравнивал/оценивал другое.
Упоминание про "прогрев" и отбрасывание первых итераций - тоже не релевантно, так как при фиксированной частоте и замере по wall clock первая итерация растворяется в 1000 повторений.
Да, и на всякий - при переключении Xeon на 3 ГГц время работы бенчмарка уменьшает вдвое с точностью до погрешности. Можно было-бы добавить эти результаты, но в них нет ничего нового/интересного.
У вас зашкаливает апломб, самоуверенность и стремление выдать желаемое за действительное.
Однако, вот должен признать, что я сам себя «подловил». Конкретно, в одном из моих ответов есть фраза: «Да, Spectre/Meltdown тоже нет», что не соответствует действительности, в той полноте смысла как это читается. На Эльбрусах всех актуальных версий (3, 4, 5, 6) можно вызвать спекулятивную загрузку в кэш, а пока не доказано обратное (т. е. пока не опубликованы результаты подобных исследований) действительно нельзя говорить что Spectre/Meltdown отсутствуют.
Думаю всем понятно, что соответствующие дизайнерские решения были заложены в актуальные версии архитектуры Эльбрус до раскрытия информации о Meltdown/Spectre, и без какой-либо экспертизы/оценки возможных проблем (в кулуарах, ваш покорный слуга, предупреждал о потенциальных проблемах из-за спекулятивного выполнения еще лет 15 назад, но к e2k это вообще никак не относится).
На данный момент мне не известно о том, чтобы кто-то завершил работу по более-менее полноценному исследованию этой проблемы в Эльрусах, включая Positive Technologies. Но в соответствии с общепринятыми правилами и практиками, раскрываться такая информация будет после реализации всех необходимых защитных мер в софте и «раскатки» этих патчей у пользователей/заказчиков.
Тем не менее, проблемы типа Spectre/Meltdown есть примерно во всех актуальных процессорах со спекулятивным выполнением. Можно предполагать, что основные игроки будут как-то решать проблему, но где заявления что проблемы будут устранены в такой-то версии или к такой-то дате?
Возвращаясь к Эльбрусам - еще в начале 2018 года обсуждались варианты защиты и мной (и, вероятно, кем-то еще) был предложен достаточно очевидный и приемлемо надежный способ защиты от «спекулятивных проблем» в последующих версиях архитектуры. Соответственно, мне сложно поверить, что в v7 эта проблема сохранится.
Поэтому, у текущих Эльбрусов со Spectre/Meltdown не хуже чем у Intel/AMD и далее по списку. В следующих версиях Эльбрусов, уверен что этой проблемы не будет.
---
Теперь давайте вернемся к моим «бредням» в комментарии к статье Касперской и Ашманова:
Утверждается что у RISC-V нет преимуществ при выходе из low-end сегмента с переходом в high-end. Ну а какие технические/технологические преимущества, скажем в сравнении с MIPS64 или AARCH64? Простота декодера тут уже особой роли не играет и x86 хорошо это подтверждает. Как где-то уже мелькало — покажите эти преимущества, либо просто используйте их если они есть.
Сравнивается текущая «поверхность атаки» RISC-V и Эльбрусов. Тут у E2K действительно неоспоримое, сравнительно «непробиваемое» преимущество, ибо раздельные стеки для адресов возврата и данных примерно отсекают все сценарии атак через переполнение буфера на стеке и атаки с использованием ROP.
Это не значит что Эльбрусы не уязвимы, но значит что подавляющее большинство атак не реализуемо или крайне затруднено, и что вероятность эксплуатирования уязвимостей существенно меньше. Сформулировать это в виде четкой, достоверной и полезной метрики не возможно, ибо недостаточно статистики и мало самих Эльбрусов. Но можно переформулировать так — практика показывает, что почти любая система на x86/ARM/MIPS (и RISC-V как подвид MIPS) имеет уязвимости эксплуатируемые через ROP. А вот на Эльбрусах эксплуатирования подобных дыр пока не было.
Утверждается что RISC-V предполагает спекулятивное выполнение в высокопроизводительных ядрах и этим закладывает фундамент для Spectre-подобных уязвимостей. Мне по-прежнему не известна информация противоречащая этому тезису, ровно как и ничего не известно о проработки в RISC-V вариантов более-менее гарантированной защиты от Spectre, как это происходит сейчас с e2k.
----
Теперь по остальным вашим аргументам.
при закрытости и малодоступности архитектуры никто Эльбрус на предмет реальных проблем особо не тестил
Ну вот как-бы начинаем, и другого пути нет, кроме как вникнуть и проверить. Но не нужно смешивать заведомо известные принципиальные проблемы в архитектурах x86/ARM/MIPS и болден-RISC с еще не найденными проблемами Эльбрусов. Ну или другими словами — в Эльбрусах искать надо, а там вон бери и взламывай (наблюдаем регулярно).
в Эльбрусе были ошибки в аппаратуре, которые при неудачной последовательности байт вообще машину клали.
Ошибки в аппаратуре были и есть у всех. Буквально у всех, всегда и с самыми разными последствиями, из которых зависание — очень даже безобидно. Глядя в Errata иногда не понятно как оно вообще живет, а тут просто зависания. Премировать надо, если молчаливых багов нет.
Про тэги можно пока забыть - это специальный режим, работоспособность которого непонятна и в продакшене они не используются - это только для каких-то специальных применений.
Так а в чем проблема, что там «непонятно», или просто не пользовались? Конечно работа в 128-битном режиме доставляет, накладные расходы и отсутствие привычных вольностей с указателями. Но используется там где нужно/затребовано.
А выделенный стэк вызовов даёт защиту от типичных атак переполнения стэка… ...Поэтому по факту Эльбрус лишь снимает потенциальный риск эксплуатирования уязвимости с переполнением стэка. Это хорошо, но глобально проблем не снимает.
Эмм, в сухом остатке:
ваше владение темой недостаточно, а рассуждения достаточно ошибочны и опровергаются (в частности и в том числе) CVE-сводками.
полной гарантии никто дать не может, т. е. двойной стек и всё остальное не означает неуязвимость Эльбрусов.
незащищенность Эльбрусов может показать какое-нибудь пробитие, либо какой-то анализ показывающий потенциальную возможность/концепт эксплоита.
Пока «на руках» мы имеем множественные разнообразные примеры эксплуатации дыр на всех популярных архитектурах, и ни одного показанного практического пробития двойного стека Эльбруса, даже без использования тегов.
Хм, этот «тест» - просто набор общеизвестных алгоритмов сортировки, подобранных и допеределанных сотрудником Google (в смысле понимаю, что я вам не авторитет). В основном он для сравнения этих сортировок между собой, в тех условиях и с теми параметрами, которые нужны запускающему.
Соответственно, было показано, что при работе на одной частоте, Эльбрус-8СВ и новейший Intel Xeon Gold 5317 выполняют некий одинаковый запрограммированный набор действий (1000 повторов каждой сортировки на 42 тысячах 64-битных элементах) за примерно равное время.
Если вы хотите выяснить что-то еще, опровергнуть результаты, либо показать что они почему-то некорректны или несостоятельны — так делайте/показывайте/доказывайте.
Ну вот видите, а вы уже пытались обвинять интел, даже не разобравшись в вопросе.
Пардон, так как-раз таки я разобрался в вопросе, написал об этом и (даже, вынужденно) оформил еще один багрепорт в поддержку Supermicro. Теперь, похоже, Ваша очередь «разобраться в вопросе».
Как выше упомянуто, этот "бенчмарк" - утилитарный инструмент для проверки и оптимизации собственных сортировок (в частности для libmdbx), и 42 тысячи там именно потому-что 42. Никакого отношения к размеру кэшей, e2k и т.п. этот код и константы в нём не имеют (кроме последнего экспериментального коммита).
Для всего остального есть/доступны исходники, берите пробуйте опровергнуть и т.п. Может действительно у меня проблемные/замедленные процы или матплата, а для Эльбруса припасено ведро жидкого азота ;)
---
Да и все ядра обоих 5317 получилось запустить на 3 ГГц. Причина соскока на 2800 была в одной из ~20 опций BIOS в X12DPi-NT6 и (видимо, всё-таки) неточности, из-за которой некоторый захардкоженный/дефолтовый суммарный бюджет по частоте на все ядра был меньше чем 3000*12 на сокет.
Вы как "специалист" утверждаете что на e2k все уязвимости (или большинство, или какая-то существенная часть, или хотя-бы одна...) эксплуатируются также легко как на x86 или болден-RISC?
Может покажите хоть один пример, либо концепт? Для любой известной уязвимости, или гипотетической, на ваш выбор.
Хм, а где и как (через чье плечо) вы увидели "IP-блоки неизвестного содержания" в e2k или в Байкалах? Или в том смысле что Synopsys и/или МЦСТ публично не отчитались за содержание? Или что "для безопасности" нужно вытравить весь "ихний/буржуйский верилог"? Вообще вы за что: открытые ядра, обмен/покупку IP, fair use/provide или железный занавес? (вопрос риторический)
Тем не менее, аргумент безопасности "достаточно железобетонный". Поэтому альтернатив e2k в области ответственных применений нет, ибо два стека и т.д. и т.п. Соответственно, будет тираж, более приемлемая цена и ресурсы на разработку.
А в целом, "болден-риск" - смешно/прикольно, конечно.
Ради интереса прогнал бенчмарк сортировок на Эльбрус-8СВ и на примерно самом последнем Xeon. Кратко:
при выравнивании частоты Эльбрус-8СВ примерно равен по скорости Xeon Gold 5317 (последнее третье поколение Xeon Scallable на Ice Lake);
есть неожиданности/странности: quick sort существенно быстрее на e2k, а radix sort наоборот (буду смотреть как будет время);
сделав мелкую правку получил +10% на двух моих сортировках.
В текущем виде использованный бенчмарк, разными алгоритмами, по 1000 раз сортирует 42000 64-битных целых и выводит затраченное время в us.
Если не ошибаюсь, исходный вариант этого бенчмарка сделал Christopher Swenson работая в Google. Я же только добавил свои сортировки (yysort1 и yysort2) и расширил паттерны данных, ну и что-то по-мелочи. Кроме полностью случайного паттерна есть и другие (весьма важные). Исходники бенчмарка не являются образцом (он сугубо утилитарный), но "в принципе" пользоваться можно. Также стоит отметить, что большинство алгоритмов сортировки "допилено" до неплохого уровня, а не просто скопипащены из учебника.
С управлением частотой на Штеуде, откровенно говоря, я замучился. Специально брал процессоры на 3ГГц, чтобы включать управление частотой и гонять бенчмарки на удобном ровном/круглом значении. Но пока так и не получилось заставить всё ядра работать на нужной частоте (похоже что постоянная работа на 3 ГГц - это вранье/маркетинг, а реальный стабильный максимум только 2800 МГц).
Поэтому я сделал проще - сровнял Xeon 5317 по частоте с Эльбрус-8СВ, т.е. задал частоту 1500 Mhz: sudo cpupower frequency-set --min 1500MHz --max 1500MHz и прогнал бенчмарк.
Intel(R) Xeon(R) Gold 5317 CPU @ 1500 ГГц + gcc version 10.3.0 (Ubuntu 10.3.0-1ubuntu1):
Риторической вопрос: А что помешает ЦРУ-шникам залить нужные "доказательства" на взломанные сервера, или вообще нарисовать их с нуля в облачной инфраструктуре, заявив что это "те самые сервера" ?
Плюсую.
Результаты RTX 3080 и 3090 были-бы очень органичны в табличках (но включая и 24 Гб), их прям хочется увидеть рядом.
Причем ведь достаточно логичный подход - локально поэкспериментировать на "кошечках", а сетку для production тренировать на арендованном DGX A100.
Может показаться, что я специально провоцирую Вас выставлять напоказ некомпетентность и "умение" притягивать аргументы за уши (примерно как в вашем крайнем ответе).
Но на самом деле, я даю пояснение к своей позиции/тезисам и отвечаю на те вопросы, которые, как мне кажется, этого заслуживают.
Уж извините, но не пишите если не в теме.
Относительно небольшой размер индустрии безопасности == Относительно небольшое количество пожарных.
Снижение рисков эксплуатации уязвимостей являются потребностью потребителей/пользователей, а не "разработчиков" в индустрии ИБ (для ИБ как-раз наоборот, чем больше потенциальных дыр/угроз, тем больше бюджет).
Не обхода проблемы, а потенциального/гипотетического обхода защиты при наличии других ошибок/недостатков в ПО и/или железе.
Если же под одним из "способов обхода проблемы" подразумеваете смену ABI, то это примерно равнозначно повторному портированию ПО. Соответственно, это должно быть сделано до начала широкого использования архитектуры, либо станет невозможным как в случае с x86.
Не "нам", а для безопасности данных/процессов/пользователей.
Не "не критично", а существенно снижает риски, но не даёт полной гарантии, ибо её нельзя дать из-за ненулевой вероятности реализации сложной атаки с участием других ошибок/уязвимостей/недостатков.
Не "решала за нас проблемы", а чтобы система команд не имела очевидных брешей в безопасности, которые в случае с RISC-V заботливо сохранены.
---
В целом похоже на ситуацию с прививкам. Озвучиваем "так небезопасно, нужна <прививка>", а в ответ весь набор аргументов антиваксеров.
Индустрия занимающаяся обеспечением безопасности, либо вынужденная ей заниматься, имеет мнение отличное от прочих «индустрий».
https://www.securitylab.ru/news/519772.php и т.д. и т.п.
Если стек адресов возврата отделен от стека используемого для передачи параметров и размещения локальных данных функции (автоматических переменных в терминах С), то ошибка приводящая к записи за пределы локального буфера не позволит переписать адрес возврата (если только не переписать всю память между стеками и т.п.). Аналогично нет возможности непосредственно подготовить в стека адресов возврата массив адресов для ROP.
При использовании ROP код в памяти не переписывается (может быть только для чтения). Инструкции с адресов стека не выполняются (NX не имеет значения). ALSR может быть не эффективен, если через "читающее переполнение" удаётся прочитать кадры стека до генерации ROP-инъекции и т.д. и т.п.
Но это не даёт гарантии, ибо (в общем случае) возможны более сложные многоэтапные атаки, начинающиеся с перезаписи указателей на стеке и/или других данных в других места. Тем не менее, разделение стеков существенно (в разы) затрудняет доведение атак до финала и снижает риски эксплуатации уязвимостей.
https://ru.wikipedia.org/wiki/%D0%9F%D0%B5%D1%80%D0%B5%D0%BF%D0%BE%D0%BB%D0%BD%D0%B5%D0%BD%D0%B8%D0%B5_%D0%B1%D1%83%D1%84%D0%B5%D1%80%D0%B0
https://ru.wikipedia.org/wiki/%D0%92%D0%BE%D0%B7%D0%B2%D1%80%D0%B0%D1%82%D0%BD%D0%BE-%D0%BE%D1%80%D0%B8%D0%B5%D0%BD%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5
https://habr.com/ru/post/266591/
https://www.securitylab.ru/search/?q=ROP
Давать мне какие-либо ответы и/или пояснения не надо.
Коллега посоветовал уточнить/пояснить "пару моментов" в моём обосновании небезопасности/нелюбви к RISC-V и фразе «бережно сохранено всё необходимое для ROP». Не думаю, что этот комментарий прочитает больше чем несколько человек, но считаю написать стоит.
Суть в том, что в RISC-ах в явном виде в аппаратуре нет стека "как на x86". Стек специфицируется/реализуется на уровне ABI посредством назначения ролей регистрам и соглашения о вызове функций, а инструкции
push,pop,callиretотсутствуют на уровне аппаратуры в явном виде и являются макросами и/или псевдоиструкциями. Программное обеспечение может реализовать поверх ISA один, два или сколько угодно стеков. Поэтому предъявлять претензии к набору команд RISC-V по поводу одного стека необоснованно — вроде-бы всё верно, но...Собственно говоря, программно реализовать два стека, т.е. отделить данные (и потенциально уязвимые буфера на стеке) от адресов возврата, можно на всех архитектурах (имеющих косвенную адресацию), включая x86, ARM, MIPS и т.д. Принципиально ничего невыполнимого нет (но будут нюансы), разница только в объеме накладных расходах, трудоёмкости и (не)привязке к возможностям и/или контролю аппаратуры.
Если возможно программно реализовать два стека на чуть менее чем любой архитектуре ЦПУ и это, прежде всего, связано со сменой ABI, то «количество стеков» — это атрибут ABI? Либо ABI (может именно этот аспект) является какой-то значимой частью архитектуры как экосистемы?
Говоря что у RISC-V один стек, я знаю о возможности его разделить сугубо программно сменой ABI. Однако, если смотреть на «экосистему архитектуры» RISC-V:
представлен только «одностековый» вариант ABI и всей экосистемы;
явно определено
reg(sp) == reg(x2), push/pop в/из RAS дляjalr;нет упоминания о втором
spдля передачи большого кол-ва аргументов и хранения локальных данных, отдельно от RAS;для разделения стеков требуется специфицировать ABI, поправить компилятор(ы)/toolchain и доперепортировать софт.
Поэтому я критикую RISC-V как одно-стековую архитектуру подверженную ROP: не предусмотрено какое-либо разрешение/запрещения переходов/возвратов к командам, нет само-синхронизации кодирования команд переменной длины.
С другой стороны, на x86 тоже можно сменить ABI, разделить стек, многократно снизив этим риск эксплуатации уязвимостей. Подобное разделение приведёт к некоторой потери плотности кода, в основном из-за заметы
pushнаmov [reg + offset]при подготовке/передачи аргументов. Но для рынка это давно табу из-за слома совместимости и необходимости допиливать тонны софта.AMD разрабатывали AMD64 как расширение ISA более 20 лет назад, думая о time-to-market и минимизации непохожести с x86_32. Ожидаемо, что тогда не думали про два стека. Но с RISC-V принципиально иначе: потеря эффективности минимальная (занимаем один регистр), а слома ABI вообще могло не быть.
Поэтому мне не ясны (не очевидны) причины, по которым для RISC-V специфицировано только «одностековое» ABI и «бережно сохранено всё необходимое для ROP и эксплуатации традиционных ошибок выхода за пределы буфера на стеке».
Немного смешались мухи и котлеты.
Вы говорите об «опциональной» безопасности конкретных реализаций ядер. В частности, например, о выключении/блокировании спекулятивной загрузки для предотвращения Spectre/Meltdown. Понятно что «так можно делать», в том числе решать/выбирать для каждого конкретного ядра (модели ЦПУ).
А я писал про проблемы ISA как таковой — сохранено всё необходимое для ROP и эксплуатации записи за границы буфера. Здесь нельзя реализовать каких-либо эффективных мер/механизмов без нарушения бинарной совместимости с ISA (Intel делал несколько подходов).
Хотя, теоретически, можно «форкнуть» и сделать RISC-6, поправив Spectre и остальные недопеределки (вот, если-бы Yando взялось, то я бы помог...).
«болген» - это, конечно, просто одна из опечаток (привык к высокому разрешению и мелкому шрифту, а зрение уже подводит - не замечаю).
Что касается тона и термина "Болден-RISC", то в этой шутке есть доля правды. Конечно, с одной стороны, хорошо что есть открытые ISA, IP и целые ядра. Но нас ждет зоопарк ядер не меньший чем зоопарк дистрибутивов Linux, и проблема зависимостей (привет
nmp), как по IP, так и по программному коду.Открытость ISA, расширяемость и доступность готовых IP, приводит к появлению массы как стартапов, так и отделов разработки собственных ЦПУ со "стартаперским духом" — когда важно быстро-быстро показать первый результат, а какие-то неудобные вопросы/проблемы замести под ковер с обещанием "потом всё порешаем, когда доплывём".
Среди таких вопросов — небезопасность RISC-V. Конечно RISC-V нельзя назвать более дырявым чем другие ISA в своих сегментах. Но для меня несколько странно/неожиданно, что в RISC-V бережно сохранено всё необходимо для эксплуатации всех традиционных ошибок/дыр.
Да, пожалуй, у меня есть определенное "профессиональное искажение". Тем не менее, свободно-бесплатная раздача ISA и ядер с явными (бережно сохраненными) проблемами с безопасностью — всё-таки начинает выглядеть как сыр в мышеловке.
При этом я (пока) не встречал человека на позиции ЛПР, который-бы понимал все сложности и проблемы связанные с управлениями этими зависимостями, и уже планировал бизнес-процессы и жизненный цикл устройств/продукции с учетом необходимости отслеживания ошибок/проблем/уязвимостей и (соответственно) необходимости обновлений и замены/отзыва проблемных устройств.
Так вот, совокупность всего вышеописанного, вместе с создаваемым хайпом, позволяю себе называть "Болден-RISC".
(думаю стоит написать статью с освещением всех этих вопросов).
Вы не владеете темой, но продолжаете изображать специалиста и гнуть свою линию, неся при этом ерунду.
1. Эксплуатация Spectre/Meltdown требует локального доступа. А на Эльбрусах дополнительно еще и возможности конструировать нативный исполнимый код (в памяти или в файлах), так как JIT-ов примерно нет.
2. Уязвимости связанные с выходом за пределы буфера и использованием ROP могут эксплуатировать удаленно достаточно часто. Но на Эльбрусах вероятность их эксплуатации кардинально ниже из-за двойного стека. Причем это без учета возможности использования защиты «тегами», которая может быть использована только в процессах подверженных рискам атаки.
3. Соответственно, на Эльбусах относительно легко защититься от Spectre/Meltdown просто адекватным системным администрированием (например, хотя-бы убрать компиляторы и запретить взводить eXecute бит у файлов). Вероятность же удаленной эксплуатации Spectre/Meltdown через ROP стремиться к нулю. Причем всё это без учета противодействия Spectre/Meltdown со стороны ядра ОС.
Поэтому, я действительно вижу отдельные недостатки, но не вижу принципиальных проблем с безопасностью Эльбрусов, особенно в сравнении с x86, ARM, MIPS и болден-RISC (aka RISC-V).
Хм, эка Вы повернули ;) Конечно можете тут крутить/вертеть слова как хотите, в том числе и мои осторожно-аккуратные формулировки о (не)эксплуатируемости Specte-подобных проблем на Эльбрусах (требуется ждать завершения работ и раскрытия информации).
От советов перечитывать и дальше получать "квалифицированные" ответы я вежливо откажусь, и подведу черту чтобы не тратить время:
1. В Эльбруса со Spectre не хуже чем в любых других процессорах со спекулятивной загрузкой. А в следующей версии архитектуры этих проблем не будет. Тогда как намерения Intel/AMD по устранению не декларированы, а в участники RISC-V (видимо) вообще не считают это проблемой.
2. В Эльбрусе отдельный стек для адресов возврата, плюс возможность использовать теги и расширенные указатели для дополнительной защиты. Поэтому риски эксплуатации ROP, включая ошибки записи за пределы буфера, double-free и use-after-free кардинально ниже.
3. У RISC-V как ISA нет значимых технических/технологических преимуществ при переходе в сегмент высокопроизводительных ЦПУ.
Хм, не увидел вопросов на которые не было-бы ответов и/или стоило-бы отвечать отдельно или еще раз. Но давайте пройдемся вместе:
Как указал в самом начале - чтобы выровнять частоту с Эльбрус-8СВ. Но, видимо, стоило подробнее пояснить, что базовая частота Xeon 5317 равна 3000 МГц и удобна тем, что ровно вдвое больше частоты Эльбрус-8СВ. Соответственно, 1500 было выбрано как удобно/равное значение после неудачи с переключением Xeon на его родные 3 ГГц.
Наверно стоило как-то обозначить, что сравнивается эффективная/наблюдаемая "скорость архитектур", как если-бы они (были сделаны по одному техпроцессу и) работали на одинаковой частоте. Но вроде-бы это и так понятно из контекста производимых действий и начала текста.
Собственно, я же уже отвечал "этот бенчмарк - утилитарный инструмент для проверки и оптимизации собственных сортировок (в частности для libmdbx), и 42 тысячи там именно потому-что 42". Проще говоря, такой размер сортируемого массива просто подходит (вроде-бы очевидно?) для сравнения скорости сортировок между собой и просто остался в исходниках с его предыдущего использования.
Еще у вас были упоминания про управление частотой в тестах на энерго-эффективность - но я сравнивал/оценивал другое.
Упоминание про "прогрев" и отбрасывание первых итераций - тоже не релевантно, так как при фиксированной частоте и замере по wall clock первая итерация растворяется в 1000 повторений.
Да, и на всякий - при переключении Xeon на 3 ГГц время работы бенчмарка уменьшает вдвое с точностью до погрешности. Можно было-бы добавить эти результаты, но в них нет ничего нового/интересного.
У вас зашкаливает апломб, самоуверенность и стремление выдать желаемое за действительное.
Однако, вот должен признать, что я сам себя «подловил». Конкретно, в одном из моих ответов есть фраза: «Да, Spectre/Meltdown тоже нет», что не соответствует действительности, в той полноте смысла как это читается. На Эльбрусах всех актуальных версий (3, 4, 5, 6) можно вызвать спекулятивную загрузку в кэш, а пока не доказано обратное (т. е. пока не опубликованы результаты подобных исследований) действительно нельзя говорить что Spectre/Meltdown отсутствуют.
Думаю всем понятно, что соответствующие дизайнерские решения были заложены в актуальные версии архитектуры Эльбрус до раскрытия информации о Meltdown/Spectre, и без какой-либо экспертизы/оценки возможных проблем (в кулуарах, ваш покорный слуга, предупреждал о потенциальных проблемах из-за спекулятивного выполнения еще лет 15 назад, но к e2k это вообще никак не относится).
На данный момент мне не известно о том, чтобы кто-то завершил работу по более-менее полноценному исследованию этой проблемы в Эльрусах, включая Positive Technologies. Но в соответствии с общепринятыми правилами и практиками, раскрываться такая информация будет после реализации всех необходимых защитных мер в софте и «раскатки» этих патчей у пользователей/заказчиков.
Тем не менее, проблемы типа Spectre/Meltdown есть примерно во всех актуальных процессорах со спекулятивным выполнением. Можно предполагать, что основные игроки будут как-то решать проблему, но где заявления что проблемы будут устранены в такой-то версии или к такой-то дате?
Возвращаясь к Эльбрусам - еще в начале 2018 года обсуждались варианты защиты и мной (и, вероятно, кем-то еще) был предложен достаточно очевидный и приемлемо надежный способ защиты от «спекулятивных проблем» в последующих версиях архитектуры. Соответственно, мне сложно поверить, что в v7 эта проблема сохранится.
Поэтому, у текущих Эльбрусов со Spectre/Meltdown не хуже чем у Intel/AMD и далее по списку. В следующих версиях Эльбрусов, уверен что этой проблемы не будет.
---
Теперь давайте вернемся к моим «бредням» в комментарии к статье Касперской и Ашманова:
Утверждается что у RISC-V нет преимуществ при выходе из low-end сегмента с переходом в high-end. Ну а какие технические/технологические преимущества, скажем в сравнении с MIPS64 или AARCH64? Простота декодера тут уже особой роли не играет и x86 хорошо это подтверждает. Как где-то уже мелькало — покажите эти преимущества, либо просто используйте их если они есть.
Сравнивается текущая «поверхность атаки» RISC-V и Эльбрусов. Тут у E2K действительно неоспоримое, сравнительно «непробиваемое» преимущество, ибо раздельные стеки для адресов возврата и данных примерно отсекают все сценарии атак через переполнение буфера на стеке и атаки с использованием ROP.
Это не значит что Эльбрусы не уязвимы, но значит что подавляющее большинство атак не реализуемо или крайне затруднено, и что вероятность эксплуатирования уязвимостей существенно меньше. Сформулировать это в виде четкой, достоверной и полезной метрики не возможно, ибо недостаточно статистики и мало самих Эльбрусов. Но можно переформулировать так — практика показывает, что почти любая система на x86/ARM/MIPS (и RISC-V как подвид MIPS) имеет уязвимости эксплуатируемые через ROP. А вот на Эльбрусах эксплуатирования подобных дыр пока не было.
Утверждается что RISC-V предполагает спекулятивное выполнение в высокопроизводительных ядрах и этим закладывает фундамент для Spectre-подобных уязвимостей. Мне по-прежнему не известна информация противоречащая этому тезису, ровно как и ничего не известно о проработки в RISC-V вариантов более-менее гарантированной защиты от Spectre, как это происходит сейчас с e2k.
----
Теперь по остальным вашим аргументам.
Ну вот как-бы начинаем, и другого пути нет, кроме как вникнуть и проверить. Но не нужно смешивать заведомо известные принципиальные проблемы в архитектурах x86/ARM/MIPS и болден-RISC с еще не найденными проблемами Эльбрусов. Ну или другими словами — в Эльбрусах искать надо, а там вон бери и взламывай (наблюдаем регулярно).
Ошибки в аппаратуре были и есть у всех. Буквально у всех, всегда и с самыми разными последствиями, из которых зависание — очень даже безобидно. Глядя в Errata иногда не понятно как оно вообще живет, а тут просто зависания. Премировать надо, если молчаливых багов нет.
Так а в чем проблема, что там «непонятно», или просто не пользовались? Конечно работа в 128-битном режиме доставляет, накладные расходы и отсутствие привычных вольностей с указателями. Но используется там где нужно/затребовано.
Эмм, в сухом остатке:
ваше владение темой недостаточно, а рассуждения достаточно ошибочны и опровергаются (в частности и в том числе) CVE-сводками.
полной гарантии никто дать не может, т. е. двойной стек и всё остальное не означает неуязвимость Эльбрусов.
незащищенность Эльбрусов может показать какое-нибудь пробитие, либо какой-то анализ показывающий потенциальную возможность/концепт эксплоита.
Пока «на руках» мы имеем множественные разнообразные примеры эксплуатации дыр на всех популярных архитектурах, и ни одного показанного практического пробития двойного стека Эльбруса, даже без использования тегов.
Хм, этот «тест» - просто набор общеизвестных алгоритмов сортировки, подобранных и допеределанных сотрудником Google (в смысле понимаю, что я вам не авторитет). В основном он для сравнения этих сортировок между собой, в тех условиях и с теми параметрами, которые нужны запускающему.
Соответственно, было показано, что при работе на одной частоте, Эльбрус-8СВ и новейший Intel Xeon Gold 5317 выполняют некий одинаковый запрограммированный набор действий (1000 повторов каждой сортировки на 42 тысячах 64-битных элементах) за примерно равное время.
Если вы хотите выяснить что-то еще, опровергнуть результаты, либо показать что они почему-то некорректны или несостоятельны — так делайте/показывайте/доказывайте.
Пардон, так как-раз таки я разобрался в вопросе, написал об этом и (даже, вынужденно) оформил еще один багрепорт в поддержку Supermicro.
Теперь, похоже, Ваша очередь «разобраться в вопросе».
Как выше упомянуто, этот "бенчмарк" - утилитарный инструмент для проверки и оптимизации собственных сортировок (в частности для libmdbx), и 42 тысячи там именно потому-что 42. Никакого отношения к размеру кэшей, e2k и т.п. этот код и константы в нём не имеют (кроме последнего экспериментального коммита).
Для всего остального есть/доступны исходники, берите пробуйте опровергнуть и т.п. Может действительно у меня проблемные/замедленные процы или матплата, а для Эльбруса припасено ведро жидкого азота ;)
---
Да и все ядра обоих 5317 получилось запустить на 3 ГГц. Причина соскока на 2800 была в одной из ~20 опций BIOS в X12DPi-NT6 и (видимо, всё-таки) неточности, из-за которой некоторый захардкоженный/дефолтовый суммарный бюджет по частоте на все ядра был меньше чем 3000*12 на сокет.
Ну это уже перебор, или клоунада какая-то.
Вы как "специалист" утверждаете что на e2k все уязвимости (или большинство, или какая-то существенная часть, или хотя-бы одна...) эксплуатируются также легко как на x86 или болден-RISC?
Может покажите хоть один пример, либо концепт?
Для любой известной уязвимости, или гипотетической, на ваш выбор.
Так сказать, покажите мастер-класс домохозяйкам из Positive Technologies?
Хм, а где и как (через чье плечо) вы увидели "IP-блоки неизвестного содержания" в e2k или в Байкалах?
Или в том смысле что Synopsys и/или МЦСТ публично не отчитались за содержание?
Или что "для безопасности" нужно вытравить весь "ихний/буржуйский верилог"?
Вообще вы за что: открытые ядра, обмен/покупку IP, fair use/provide или железный занавес?
(вопрос риторический)
Тем не менее, аргумент безопасности "достаточно железобетонный".
Поэтому альтернатив e2k в области ответственных применений нет, ибо два стека и т.д. и т.п.
Соответственно, будет тираж, более приемлемая цена и ресурсы на разработку.
А в целом, "болден-риск" - смешно/прикольно, конечно.
Ради интереса прогнал бенчмарк сортировок на Эльбрус-8СВ и на примерно самом последнем Xeon. Кратко:
при выравнивании частоты Эльбрус-8СВ примерно равен по скорости Xeon Gold 5317 (последнее третье поколение Xeon Scallable на Ice Lake);
есть неожиданности/странности: quick sort существенно быстрее на e2k, а radix sort наоборот (буду смотреть как будет время);
сделав мелкую правку получил +10% на двух моих сортировках.
В текущем виде использованный бенчмарк, разными алгоритмами, по 1000 раз сортирует 42000 64-битных целых и выводит затраченное время в us.
Если не ошибаюсь, исходный вариант этого бенчмарка сделал Christopher Swenson работая в Google. Я же только добавил свои сортировки (
yysort1иyysort2) и расширил паттерны данных, ну и что-то по-мелочи. Кроме полностью случайного паттерна есть и другие (весьма важные). Исходники бенчмарка не являются образцом (он сугубо утилитарный), но "в принципе" пользоваться можно. Также стоит отметить, что большинство алгоритмов сортировки "допилено" до неплохого уровня, а не просто скопипащены из учебника.С управлением частотой на Штеуде, откровенно говоря, я замучился. Специально брал процессоры на 3ГГц, чтобы включать управление частотой и гонять бенчмарки на удобном ровном/круглом значении. Но пока так и не получилось заставить всё ядра работать на нужной частоте (похоже что постоянная работа на 3 ГГц - это вранье/маркетинг, а реальный стабильный максимум только 2800 МГц).
Поэтому я сделал проще - сровнял Xeon 5317 по частоте с Эльбрус-8СВ, т.е. задал частоту 1500 Mhz:
sudo cpupower frequency-set --min 1500MHz --max 1500MHzи прогнал бенчмарк.Intel(R) Xeon(R) Gold 5317 CPU @ 1500 ГГц + gcc version 10.3.0 (Ubuntu 10.3.0-1ubuntu1):
Эльбрус-8СВ @ 1500МГц + lcc:1.25.17:May-16-2021:e2k-v5-linux
Символами
<<<помечены результаты после небольшой экспериментальной правки.Соответственно, у Эльбрусов я не вижу особых/неустранимых проблем с производительностью, но вижу отсутствие принципиальных проблем с безопасностью.
Кто-то из маркетологов штеуда/intel перешел в ADATA?
Заказал попкорна смотреть как YADRO(включая все хвосты ибм) и Huawei(включая все приобретения) огородят от госзаказа к концу года.
Риторической вопрос: А что помешает ЦРУ-шникам залить нужные "доказательства" на взломанные сервера, или вообще нарисовать их с нуля в облачной инфраструктуре, заявив что это "те самые сервера" ?
тик, тик, тик,
тик-ток, тик-ток, тик-ток,
ток, ток, ток,
кирдык