Линус Торвальдс предложил (https://lkml.org/lkml/2018/11/19/37) пересмотреть механизм активации патчей STIBP (Single Thread Indirect Branch Predictors), предлагающих дополнительную защиту от проявления уязвимостей класса Spectre v2. Данные патчи недавно были включены (https://lkml.org/lkml/2018/10/23/469) в находящуюся в разработке ветку 4.20 и бэкпортированы в стабильный выпуск 4.19.2. При применении STIBP в текущем виде пользователи отметили существенное снижение производительности выполнения некоторых приложений при применении технологии одновременной многопоточности (SMT или Hyper-Threading).
Так как падение производительности достигает 50%, по мнению Линуса, применение STIBP лишено смысла, так как проще и надёжнее вообще отключить SMT/Hyper-Threading, что обычно и делают люди, озабоченные безопасностью. Возникает вопрос, нужно ли включать STIBP по умолчанию, когда у тех, кому действительно важна безопасность, SMT/Hyper-Threading уже отключен. Для обычных пользователей потеря производительности в 50% является существенным фактором и возникает сомнение, стоят ли данные потери блокирования теоретической уязвимости.
Линус считает (https://lkml.org/lkml/2018/11/19/69) маловероятным появление практических атак на базе Spectre v2, так как в обычных пользовательских системах основной целью атаки являются браузеры, которые уже добавили защиту на своём уровне (угроза остаётся для изолированных процессов с JIT, для которых может быть выработан метод выборочной защиты). Предлагается по умолчанию применять только методы защит от Spectre, не приводящие к большому падению производительности, а дополнительные методы применять выборочно или в виде опции.
Арьян ван де Вен (Arjan van de Ven) из компании Intel рассказал (https://lkml.org/lkml/2018/11/19/69), что Intel и AMD не рекомендуют применять STIBP по умолчанию, так как данную функциональность можно сравнить с очень тяжёлым молотком, который не используется в повседневной работе, но необходим при определённых обстоятельствах. Предложенный в обновлении микрокода механизм STIBP позволяет через установку специального бита в регистре CR0 управлять отключением кэшей процессора, что следует делать не повсеместно, а только в выборочных особо критичных ситуациях. Тип Чен (Tim Chen) из Intel
предложил (https://lkml.org/lkml/2018/11/19/85) для выборочного блокирования атак на sandbox включать STIBP только при явном запросе через prctl (http://man7.org/linux/man-pages/man2/prctl.2.html) или для процессов запрещающих создание core-дампов памяти (PR_SET_DUMPABLE), таких как sshd.Что касается падения производительности при применении STIBP-патчей в ядре 4.20, то результат очень сильно зависит от вида нагрузки. Например, тестирование в пакете SpecInt Rate 2006 показывает уменьшение пропускной способности на 21%, а тесты Phoronix демонстрируют (https://www.phoronix.com/scan.php?page=article&item=linux-42...) снижение производительности от 3 до 20%. Инго Молнар (Ingo Molnar), известный разработчик Linux ядра и автор планировщика задач CFS, комментируя (https://lkml.org/lkml/2018/11/19/266) ситуацию, предложил сделать обязательным отражение в списках изменений сведений о тестировании производительности при добавлении любых механизмов обхода проблем.
URL: https://www.theregister.co.uk/2018/11/20/linux_kernel_spectr.../
Новость: https://www.opennet.dev/opennews/art.shtml?num=49636
Хорошо, что Линус на редкость адекватный человек, в отличие от параноиков-истеричек.
Дайте нам (не)спокойно истерить!
> Дайте нам (не)спокойно истерить!Истерите пожалуйста, но не в коде ядра.
Вы ущемляете права паранои^W людей с отличающейся подозрительностью и истери^W людей с отличающейся социальной реакцией! Может, вы еще хотите, чтобы проектами руководили компетентные люди?
(Это все сарказм, если что).
> (Это все сарказм, если что)Не такой уж и сарказм в контексте данного ресурса.
Вся суть этих уязвимостей в том, что их трудно обнаружить. Открываешь браузер на какой нить сайт, а он ворует твои данные впн соединений.
Не так. Вот как надо:Открываешь какой-нибудь чорный-чорный сайт, а там чорный-чорный эксплоит ворует твои зелёные-зелёные деньги!!!11111111РАС
А что если обычный белый-белый сайт кто-то тихо взломал? Причём для этого достаточно просто получить виртуальную машину на том же хосте, что и белый сайтик.
Так-то смех смехом, а практика не смешная на самом деле.https://blog.mozilla.org/security/2015/08/06/firefox-exploit.../
Можно подумать что эта защита 100% панацея. Есть ещё куча уязвимостей, в том числе софтварных, но о них почему-то все забыли. А ещё забыли как впилили в веб вебассембли и прочий шлак, который добавил ещё миллион уязвимсотей.
Но софтверные уязвимости хоть устранять можно на порядок меньшими потерями.
Сколько же вы, дeбилы, будете пугаться wasm только потому, что это страшное слово сильно отличается от привычного, но не менее "опасного" asm.js?По факту - те же яйца, только сбоку. Дизассемблируй wasm и получи ту же читабельность (на самом деле даже большую) чем asm.js!
А ещё в браузеры когда-то добавили js, который добавил миллион уязвимостей. Да и вообще, когда-то изобрели компьютер, из-за которого появились все эти уязвимости. Как же хорошо было без компьютеров, правда?
В браузерах отдельные защиты реализуются
>Линус на редкость адекватный человекЗвучит как "пишешь вам патчи, пишешь, занимаешься неблагодарным делом, так оно ещё и в половину медленней становится, f*** you intel & users"
А потом на конференции: "So Intel, fuck you!".
Забудь!
Линуса же на ковёр вызывали ... он теперь CoC-нутый и не торт энимо :)
> Хорошо, что Линус на редкость адекватный человек, в отличие от параноиков-истеричек.Занятно, но поступил он в итоге также как "параноики-истерички" - предложил отключать HT тем, кому это важно.
Одна и та же мысль, высказанная Тео и Линусом у опеннет-линуксоидов вызывает противоположные реакции. Как же так?
Может это не Тео и команда - онанирующие на безопасность обезьяны, а линуксоиды - онанирующие на Линуса невежды?
Ты что-то путаешь, параноики-истерички не смотрят, нужно это кому-то или нет, они бегают по форумам и визжат, что всё пропало, и срочно нужно всё отключать, заколачивать патчами, или вообще переходить на сверхсекурные архитектуры, а если тебе это не нужно, то ты тупой хомяк. Вот это как раз онанирующие на безопасность обезьяны.
> Ты что-то путаешь, параноики-истерички не смотрят, нужно это кому-то или нет, они бегают по форумам и визжат, что всё пропало, и срочно нужно всё отключать, заколачивать патчами, или вообще переходить на сверхсекурные архитектуры, а если тебе это не нужно, то ты тупой хомяк. Вот это как раз онанирующие на безопасность обезьяны.В таком случае, параноиков-истеричек не наблюдается вовсе. Чинить узявимости, безусловно необходимо, рассматривать варианты использования более надёжных архитектур - тоже абсолютно адекватно и не содержит никакой истерики. И того, кто считает хорошей идеей положить пиcю на исправление уязвимостей, умным называть сложно, это факт.
Но никакой истерики насчёт всего этого я не наблюдаю. В отличие от искромётных шуток над Тео, когда он внедряет какую-то секурити-фичу. Так как Тео в очередной раз оказался прав, считаю необходимым напомнить линуксоидам-смехунам о том, что они и их ценности из себя представляют.
Напомни-ка: что он там такого особенного внедрил чтобы, например, ХертБлид бэкдор не сработал?
Подсказать? --- Ни-че-го.
Ну только на сферических конях в вакуумах тормозной и никому ненужный OpenBSD и может отыгрываться...
Что-то он там где-то от кого-то услышал что гипертрединг надо отключать и вот уже даёт все "советы от супер-хакера", т.е. от себя личноНапоминает такие же тупые "советы от гуру" по оптимизации винды, которые копировались (и копируются до сих пор) по всем интернетам, типа: "выставите вручную размер файла подкачки в полтора раза больше чем есть оперативки потому что винда 98 плохо умеет выбирать размер, то ли дело мы!!!!" или "поставьте виртуальный RAM-диск и туда поместите файл подкачки чтобы ускорить систему!"
> Ну только на сферических конях в вакуумах тормозной и никому ненужный OpenBSDничего что ненужно-openbsd и ее поделка libressl пострадала от ВСЕХ уязвимостей следом за heartbleed? (не считая какой-то малопонятной мелочи, как обычно, срабатывающей только в сферическом вакууме при настройках, сделанных засланными шпионам)
это тот же самый выбор белок-истеричек, к безопасности имеет не то что никакое, а отрицательное отношение, судя по некоторым всплывшим в свое время багам - там могут быть очень-очень интересные дырки, не вызвавшие особого ажиотажа только в виду полной никчемности погони за неуловимыми Джо.
> или "поставьте виртуальный RAM-диск и туда поместите файл подкачки чтобы ускорить
> систему!"так это ж правильный совет - мы ж заимплементили это в виде zram! ;-)
> ничего что ненужно-openbsd и ее поделка libressl пострадала от ВСЕХ уязвимостей следом за heartbleed?Ничего, что libressl появился как ответ на heartbleed в openssl?
Но ты продолжай, не все лужи ещё газифицированы.> там могут быть очень-очень интересные дырки
И обратного никогда не утверждалось. То, что разработчики OpenBSD стремятся обеспечить наивысший уровень безопасности по умолчанию, не значит, что дыр там нет вовсе. Это же так очевидно.
>> ничего что ненужно-openbsd и ее поделка libressl пострадала от ВСЕХ уязвимостей следом
>> за heartbleed?
> Ничего, что libressl появился как ответ на heartbleed в openssl?ничего.
> Но ты продолжай, не все лужи ещё газифицированы.ты бы читать поучился - или хотя бы головенкой думать.
> И обратного никогда не утверждалось. То, что разработчики OpenBSD стремятся обеспечить
> наивысший уровень безопасности по умолчанию, не значит, чточто они это умеют делать. Точка.
они выкатили свой "ответ", когда проблему уже "решили" в штатном openssl. Заявляя что благодаря их "вырезанию ненужного кода" они обеспечат всем защиту от других, аналогичных проблем.
_ни_одна_ из серьезных проблем openssl с того момента этих вырезателей, насколько я помню, не обошла стороной. А сейчас им и вовсе приходится не вырезать, а копипастить (чему лицензия openssl несколько не способствует).
то есть миссия успешно провалена. Специфических эксплойтов именно этой версии нет ровно потому, что нафиг никому не интересна. Но фанаты продолжают бить поклоны иконе Тео.
>то есть миссия успешно провалена.Ну я бы так не сказал
Тео Де Раадт ведь пропиарился и денег собрал на ешё одну ненужную и дырявую библиотеку
А Вы что-то ещё хотели?
> Напомни-ка: что он там такого особенного внедрил чтобы, например, ХертБлид бэкдор не сработал?А кто внедрил-то?
Вот тот-то и оно-то. А сейчас Тео меры принял, Линус оподливился и повторил за Тео.
Зачем ты принёс свой хертблид, ты что, не понимаешь, в чём разница ситуаций?
Или ты думаешь, что есть хоть кто-то, предвосхитивший в своём коде все будущие потенциальные проблемы в безопасности?
> В таком случае, параноиков-истеричек не наблюдается вовсеЯсно, понятно XD
> Занятно, но поступил он в итоге также как "параноики-истерички" - предложил отключать HT тем, кому это важно.Ну дык, всё ж логично. SMT теоретически позволяет удвоить производительность. Патчи ядра, закрывающие дырки, снижают производительность вдвое, причём не факт ещё, что полностью защищают. Так какой смысл тогда от SMT для людей, которым важна безопасность?
Он уже перешёл на AMD и Gentoo?
>Арьян ван де Вен (Arjan van de Ven) из компании Intel рассказал, что Intel и AMD не рекомендуют применять STIBP по умолчанию, так как данную функциональность можно сравнить с очень тяжёлым молотком, который не используется в повседневной работе, но необходим при определённых обстоятельствах.Нет, это SMT/HT - дырявый костыль, который непригоден для повседневной работы, а необходим только для накрутки тестов.
IBM-у скажите, а то они бедные понапридумывали POWER-ов с 4-8-потоками на ядро, и знать не знают, что это костыль.
Иди читай статью "Protecting your POWER9 servers against “Spectre” and “Meltdown”"
https://www.ibm.com/support/knowledgecenter/en/POWER9/p9hby/...Такая же помойка как и Intel
Есть разница между модным RISC и пинаемым всеми CISC.
RISC по своей структуре команд плохо нагружает исполнительные устройства. И создание нескольких очередей на блок исполнительных устройств одно из решений данной проблемы. (один поток грузит по близкой ссылке адрес операнда, другой читает операнд из памяти, третий выполняет собственно команду, четвертый перепрыгивает свои операнды.) В CISC, обычно, нет избыточных операций и большая часть операций либо ждет загрузки из памяти в кеш, либо выполняет действия. Поэтому эффект не такой осязаемый.
Они знают что такие сервера стоят в локальной сети предприятий и чтобы написать своё ПО для него написать которые бы эксплуатировало уязвимость нужно получить одобрение из айбиэм.
Spectre покажет им что есть что.
>SMT/HT - дырявый костыль, который непригоден для повседневной работы, а необходим только для накрутки тестовТак непригоден, что рендерится в vray/arnold за ночь с ним и сутки без него. Ага-ага.
Подумал бы, прежде чем писать.
> Так непригоден, что рендерится в vray/arnold за ночь с ним и сутки без него.Вы таки утверждаете, что рендеринг является повсеместно-повседневной работой?
>Вы таки утверждаете, что рендеринг является повсеместно-повседневной работой?Таки да. Как минимум, большинство знакомых с этим сталкиваются.
Человек-анекдот(ический пример) пощади!
Ты не понимаешь, что прямо сейчас опеннет в твоём браузере рендерится на CPU и с HT это было бы намного быстрее?
И точно! Добавил в резюме строку "Занимаюсь рендерингом более 15 лет!"
На практике с HT на интелях это обычно выходит медленнее.
>Таки да. Как минимум, большинство знакомых с этим сталкиваются.Большинство членов африканского племени тумба-юмба едят человечину. Значит ли это, что человеческое мясо должно продаваться в магазинах Исландии?
Нет конечно. Процессоры существуют только чтоб в Дотан гонять.
>непригоден для повседневной работы
>Вы таки утверждаете, что рендеринг является повсеместно-повседневной работой?А зачем вы таки вводите новое понятие в течение разговора?
Это, конено, не повсеместно-посведневая работа, но для кого-то очень даже повседневная, пусть даже если она не является таковой в вашем кейсе.
Говорю как человек, сидящий рядом с отделом видеопродакшена.
> сидящий рядом с отделом видеопродакшена.И что весь отдел на линуксе? Не? А что вы его притянули в обсуждения патчей ядра? А?
> Так непригоден, что рендерится в vray/arnold за ночь с ним и сутки без него. Ага-ага.Подумал бы, прежде чем писать.
Когда тестировал обработку mp3 лет 5 назад, HT давал 30%, не более. Прирост до 2-х раз слабо верится. :)
Когда идел на гентухе, ядро при включенном НТ компилялось ~ в 2 раза быстрее
>ядро при включенном НТ компилялось ~ в 2 раза быстрееПотом проснулся, да?
> перестал пользоваться гентой
> проснулсяНу, можно и так сказать XD
Но почему?)
А количество потоков при этом одинаковое?
Вот как раз именно рендеринг HT/SMT не могут ускорять кратно даже теоретически.
Все зависит от количества потоков, которые может запускать программа. В принципе на ядро их можно пускать 2. Один поток ждет ввода-вывода, второй считает. Причем HT даже немного ускоряет это дела - не надо лишний раз полностью контекст переключать. Но беда с HT в этом смысле, что виртуальные ядра заменили реальные, а реальные стали светить в другом месте. А 4 потока на ядро - чересчур. Если программа в расчете на это, запускает столько потоков сколько ядер, то какие-то ядра не загружены, пока ждут, если нет HT.
> рендерится в vray/arnold за ночь с ним и сутки без негоС защитой от Spectre v2 будет рендериться сутки с ним и двое без него. Не проще отключить HT?
Не проще ли отключить дeбильную защиту?
Тогда твой рендеринг будет не твой ... и даже не мой! (С) :)
> Тогда твой рендеринг будет не твой ... и даже не мой! (С)а он и так уже давно...
> Не проще ли отключить дeбильную защиту?1. Имеет ли смысл вкладывать человеко-часы в добавление защиты, если основным юзкейсом будет "отключить её"?
2. Защита так реализована, что на некоторых тестах даже в отключенном виде приводит к 30% падению производительности.Нет, не проще.
>SMT/HT - дырявый костыль, который непригоден для повседневной работы, а необходим только для накрутки тестовЯ этот костыль отключаю при сборке ядра ещё с середины 2000-х. Тогда это рекомендовалось по другой причине: HyperThreading, на самом деле, часто приводил к снижению производительности на реальных задачах. Так что, к повышеннной производительности от его наличия не привык, если таковая действительно имела место быть.
Вот теперь задуваюсь, нафига переплачивать, покупая Ryzen 5, 7, если этой возможностью не пользоваться?
На Ryzen'ах SMT - очень хорош, +10-20% к производительности во многих задачах. И не дыряв.
А вот и супер гуру-оптимизаторщики из поста #194
>непригоден для повседневной работыО как, а мужики-то и не знали. Теперь придется покупать шестнадцатиядерник вместо восьмиядерника
Интересно, когда очередь видеокарт придет?
на выявление такого рода уязвимостей.
Когда научатся видеонарты между процессами делить эффективно.
Майнинг ферма на 2х ядерном celeron и 8 видеокарт? Нет не слышал.
на майнинг-ферме можно хоть в ring0 всё гонять
Чукча ветки не читатель?
Просто он, очевидно, понимает истинную ценность виртуальных фантиков. В отличие от.
на ферме крутится небольшой жёстко определённый набор софта, который не грузит скрипт откуда попало, дальше она закрыта файрволлом примерно для всего, если хозяин не полный дeбил. Внутри там защищаться не от чего.
более того, если ее поломают - то только через тот самый скрипт (поскольку он ходит к пулу за новыми заданиями, это и есть уязвимое место) - а ему и так доступно все, что вообще на этой системе есть ценного, и не нужно подбирать никакие другие данные в памяти.порнуху с котятками даже полный ди...л хозяин будет смотреть на другом ящике, на этом видеокарты все заняты.
А загуглить Nvidia Specter религия не позволяет? Песец давно пришел.
Недавно проскакивал сентябрьский доклад http://www.cs.ucr.edu/~zhiyunq/pub/ccs18_gpu_side_channel.pdf с методом определения содержимого экрана другого процесса через side channel атаку на видеопамять. Но там озвучены уже давно известные проблемы и для атаки требуется запуск вредоносной OpenGL- или CUDA-программы.
//offtop> Недавно проскакивал сентябрьский доклад http://www.cs.ucr.edu/~zhiyunq/pub/ccs18_gpu_side_channel.pdf
> с методом определения содержимого экрана другого процесса через side channel атаку
> на видеопамять. Но там озвучены уже давно известные проблемы и для
> атаки требуется запуск вредоносной OpenGL- или CUDA-программы.так вот как в Wayland'е скриншоты снимают?
Резюмируя: видится оптимальным использование автоматической проверки на наличие SMT/Hyper-Threading перед включением STIBP.
>Резюмируя: видится оптимальным использование автоматической проверки на наличие SMT/Hyper-Threading перед включением STIBP.и автоматического отключения, трололо.
А когда обнаружат Specter 3,4,5...99 - отключить пользователю вся ядра кроме одного.
Для его же безопасности.
не - тогда уже начнут отключать пользователя.
Торвальдс был бы куда адекватнее, если бы озадачился целесообразностью становиться сообществу рачком перед вендорами и поддерживать этот зоопарк дырявого железа. Запилил бы глобальный краудфандинг на чистые от закладок машинки. Сколько времени свободного у разрабов бы появилось! Занимались бы спортом и не дохли перед мониторами от сердечных заболеваний, как мухи.
> Сколько времени свободного у разрабов бы появилось!Потому что никто бы не профинансировал, как в своё время хотелку Шаттловорта?
Хотелка Шаттловорта теперь вращается на Самсунгах.
> Торвальдс был бы куда адекватнее, если бы озадачился целесообразностью становиться сообществу рачком перед вендорами и поддерживать этот зоопарк дырявого железаОсновных спонсоров Линукс фондейшн загуглите.
Что сказать-то хотел?
Вы весьма наивны
Ну, допустим, он собрал. Кто бы их покупал? В каком количестве? Для каких целей? Кто бы их производил (не сам же Линус)? С какой себестоимостью за единицу? Где это всё продавать? Как доставлять покупателю? Кому осуществлять поддержку пользователей? ... Оно ему вообще надо?Если это и тролль-пост, то как-то уж настолько наивно, что даже толсто.
Почему Торвальдс все эти вопросы должен решать единолично? Существует разделение обязанностей. Желающие заниматься оргвопросами нашлись бы.
> Желающие заниматься оргвопросами нашлись бы.Это не оргвопросы, это бизнес-план. И с вероятностью 99% он провальный т.к. круг тех, кому это действительно надо (зачем?) очень маленький, а рынок железа и так перенасыщен.
Все ровно те же вопросы, кстати говоря, к примеру, стоят и перед МЦСТ с её Эльбрусами, но там хотя бы заказчики есть (причём весьма специфические), а следовательно какой-никакой рынок сбыта, и у них, ни шатко ни валко, но в общем-то что-то получается.
> Запилил бы глобальный краудфандинг на чистые от закладок машинки...... которые потом за миллион баксов\штука продавались бы.
Или даже не продавались. Как убогие эльбрусы, например.
А эти ребята чем, по вашему, занимаются?
Очень адекватное предложение!
А что еще остается? Выкинуть все процессоры с 2012 в помойку?
Все на RISC-V? Где кстати они в продаже?
Отключить всем HT/SMT? И все ядра кроме одного для надежности?
> А что еще остается?Кому? Предложение направлено разработчикам ядра, а не лично Вам. Альтернатива применять патчи принудительно.
> Выкинуть все процессоры с 2012 в помойку?Для начала определитесь что Вам нужно максимальная многопоточная производительность или максимальная безопасность.
Если и то и то, то ознакомтесь с новостью по внимательней.Даже если Вам нужно и то и то
Процессоры Intel i5 не имеют HT (если не ошибаюсь).
AMD FX не имеют SMT.
Выкидывать не обязательно, даже в некоторых процессорах и отключать нечего.
> Отключить всем HT/SMT?Читайте Выше, если не осилили прочитать и понять новость.
> И все ядра кроме одного для надежности?Этого делать не нужно.
> Процессоры Intel i5 не имеют HT (если не ошибаюсь).Всё верно. Ещё есть i7 9700k - 8 ядер без HT + пара фиксов мельдония в хардваре. Я как раз себе такой взял вместо i5 4670.
правильно, покупайте наших слонов!
Именно такой процессор проработал год и умер (точнее он то работает), но не возможно даже винду на нём переустановить. 30К руб на ветер. Пришлось из-за этого попасть на покупку новой материнской платы, и нового процессора.Ктож знал, что процессор дохлый(
>такой процессор проработал год
> i7 9700k
> Launched October 19, 2018
> ГОДЕще чего расскажешь?
Да он, наверное, просто у китайцев инженерный образец купил.
>умер (точнее он то работает), но не возможно даже винду на нём переустановитьЧто-то плохо парсится. Как это?
Intel вместо Minix в прошивках теперь устанавливает форточки, видимо.
Для каких задач?
> Процессоры Intel i5 не имеют HT (если не ошибаюсь).Имеют.
https://laptoping.com/cpus/wp-content/uploads/2016/10/Intel-...
Ну вот почти год прошёл, а процессоров залатанных невидно на горизонте...
i9 9900k поокупай да.
>Компания Intel представила сегодня девятое поколение процесоров Intel Core. Первые чипы в линейке предназначены для энтузиастов. ... и имеют аппаратную защиту от уязвимостей Spectre и Meltdown.
> i9 9900k поокупай да.
>>... и имеют аппаратную защиту от уязвимостей Spectre и Meltdown.В которой немедленно найдут мельдоний.
> и имеют аппаратную защиту от уязвимостей Spectre и Meltdown.тут без подробстей не обойтись:
под фразой "аппаратная защита" может подразумеваться что угодно :-) ,
вкючая "вызывайте чистку кэша перед опасной операций -- через вот эту новую аппаратную инструкцию!" и при этом "опасные места ищите сами!".
ну или может быть другая ситуация "аппаратная защита есть, но ОТКЛючена поумолчанию и НЕ рекомендована к использованию (из-за побочных эффектов производительности). но для галочки мы её сделали"
Там всего лишь микрокод новый вшили для одной из многочисленных дыр
И он работает не сам по себе а лишь с уже встроенными костылями в саму ОС...
https://www.youtube.com/watch?v=5ko6vzCUykg
Нет там аппаратной защиты от Spectre, только Meltdown и l1tf
> только Meltdown и l1tfДогнали свои же Атомы. :)
А отключить как?
Для Ubuntu так https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAn...
Не раьотает 50% опций
Представляю как взбесятся продажи у первого выпустившего процессор без уязвимостей медтдаун спектре. Многие же не обновляют системы только потому что ждут камни с этими багфиксами.
Никак. Всем на...ть. Даже половина уязвимых сайтов HeartBleed не пофиксили до сих пор.
Без мылдауна - верю, это чисто проблема интела.Без спектра - фигушки, это архитектурная проблема. Причём архитектурная безотносительно конкретной реализации, подвержены что x86, что arm, что mips, если есть спекулятивное выполнение.
Поэтому заткнуть это дело будет совершенно непросто, а от спекулятивного выполнения не отказаться - процы начнут летать низенько-низенько.
Чистить вовремя (читать - на практике - на каждый чих, "вовремя" тут очень скользкое понятие) очередь/TLB/кэш - тоже самое, что уже и видим даже со всеми инструкциями-хелперами производительность прососала уже -40%, и то ли ещё будет.
> уже -40%, и то ли ещё будет.Во времена Pentium II можно было отключить L1 кэш в БИОС некоторых плат. Попробовал. Не дождался загрузки Windows 98.
Имею в виду сравнительно доступные, а не то что 9900...
всё интересней и интересней
в погоне за прибылью сначала наделали кучу железного лома на корню игнорируя безопасность, а затем начинают героически бороться с последствиями
Вот только не говорите что проектировщики этого всего были не в курсе потенциальных уязвимостей их архитектуры, там сидят отнюдь не дураки которые которые не могут просчитать последствия на несколько шагов вперед.
Как распознать 14-летнего подростка? У него весь мир делится на дураков и гениев со сверхчеловеческими способностями.
а еще мир делится на тех кто читает внимательно и тех кто читает и как следствие понимает по диагонали
я говорил о том что при проектировании они осознанно пошли на нарушение безопасности своей архитектуры дабы в свое время задавить конкуренцию, сейчас это им аукается, но время уже прошло и имеем то что имеем
где ты тут увидел дураков и гениев, это все порешал рынок, сынок
> при проектировании они осознанно пошли на нарушение безопасностиИнфа прямиком из астрала?
а вы хотите верить в то что это всё случайность и банальная некомпетентность профессиональных инженеров ?
Это не то и не другое, это очередное, миллиардное по счёту проявление ограниченности человеческого внимания и мышления.
те кто там сидят просчитывают только те последствия, за которые им зарплату платят. Если им за безопасность до сих пор не доплачивали, они и не заботились.
Разработчики не принимают решения, а менеджер ради красивого графика маму продаст, впарит любое г-но, а потом обвинит во всех грехах разработчика
Все так. Картина выглядела как при любой разработке. Инженер работает, получает деньги, кормит семью. На работе задачи, он их решает. На задачи выделено время, люди. Если времени или людей не хватает используется наиболее простое решение и неважно насколько оно правильное. Менеджер ставится в известность, ЕСЛИ ошибка замечена. И менеджер принимает решение о выделении дополнительных ресурсов на исправление ошибки ЕСЛИ посчитает нужным.
Никто не будет просто так бесплатно сидеть и делать безопасный HT для Intel просто потому что это честно.
> Вот только не говорите что проектировщики этого всего были не в курсе потенциальных уязвимостей их архитектурыБыли, но маркетологи в их голове взяли вверх. А потом они выпустили i9, который, якобы, защищён от этих уязвимостей на аппаратном уровне.
> It's apparently better to just disable SMT entirely, which is what security-conscious people do anyway.
> надёжнее вообще отключить SMT/Hyper-Threading, что обычно и делают люди, озабоченные безопасностьюПрикольно, раньше он этих самых людей
https://www.opennet.dev/opennews/art.shtml?num=48787
> Дополнение: Тео де Раадт (Theo de Raadt) публично предупредил о наличии серьёзной уязвимости в реализации HyperThreading,
> рекомендуется отключить эту опцию для любых компьютеровназывал немного другими словами, на букву m. И анонимы опеннета были с ним очень, очень солидарны.
ну так он же специально отпуск брал, потренироваться выговаривать "озабоченные безопасТностью" вместо м** (и может быть даже - "потрясающе!" вместо "не-зди!")
Тео - орёл. С самого начала принял самое верное решение насчёт HT. Так смешно видеть, как пeрeпончатые вскрываются на наших глазах и демонстрируют полное непонимание вопроса и двойные стандарты. Впрочем, с таким лидером, как Торвальдс, который является абсолютным дилетантом в ИБ со своим "security problems are just bugs" это и неудивительно.
Какой поп, такой и приход.
> является абсолютным дилетантом в ИБ со своим "security problems are just bugs"Всем, кто обсуждает безопасность, нужно в обязательном порядке читать "хакер в столовой". Просто для общего развития.
>> является абсолютным дилетантом в ИБ со своим "security problems are just bugs"
> Всем, кто обсуждает безопасность, нужно в обязательном порядке читать "хакер в столовой". Просто для общего развития.Забавно, что сатирическая история, призванная показывать, что излишние меры безопасности смешны и неадекватны стала иллюстрацией того, что любые меры безопасности смешны и неадекватны.
Что сказать-то хотел? Тео в очередной раз показал, что шарит и что его решения защищают не от голосов в его голове, а от реально существующих угроз безопасности. Линус повторил за тем, кого считает мастурбирующей обезьяной. Ну и причём тут твой уже сто лет как седой хакер с солонкой?
В данной истории сторонники "солонок на цепях" (Тео) оказались правы, а противники (Линус) оподливились.
> Тео в очередной раз показал, что шарит и что его решения защищают не от голосов в его голове, а от реально существующих угроз безопасности.А речь не о Тео. Тео не предлагает накладывать на ядро десяток патчей (под каждую уязвимость свой), каждый из которых опускает производительность вдвое. Это как раз предлагают фанаты Линуксоиды.
> Линус повторил за тем, кого считает мастурбирующей обезьяной.
Линус прав. Хочешь рочить на безопасность - включи hyperthreading и сиди накладывай патчи, пока процессор не достигнет производительности "ура, я снова в 2008", и хвастайся всем, что у тебя система работает быстрее, чем без HT. Нужна реальная безопасность - просто отключи HT. Нужна скорость - включай HT и имей ввиду, что тебя могут... поиспользовать.
> В данной истории сторонники "солонок на цепях" (Тео) оказались правы, а противники (Линус) оподливились.
Сторонники "солонок на цепях" тут как раз те, кто в ядро всылает патчи, уменьшающие производительность в разы. А Линус просто сказал: боитесь отравиться, не используйте солонки, а приносите соль из дому.
Друзья, ответьте, а нельзя ли эту самую спекулятивность вынести из функций процессоров и перенести данную задачу на компиляторы, ОС и т.д. (в общем, на сам софт)?
можно, только процессор тогда будет MIPS называться
хотя и у старухи бывает оказывается, хоть и не часто: https://www.mips.com/blog/mips-response-on-speculative-execu...
Ага, значит Байкал-Т1 может быть подвержен вариантам 1 и 2.
интересно что китайский "сын дракона" тоже делает branch prediction, как минимум версия что у STMicro, вполне возможно что и они подвержены
> Друзья, ответьте, а нельзя ли эту самую спекулятивность вынести из функций процессоров
> и перенести данную задачу на компиляторы, ОС и т.д. (в общем,
> на сам софт)?Можно. И это одна из самых многообещающих и перспективных, но почему-то весьма труднореализуемых вещей в компьютерных делах. Много лет над этим бьются чуть не худшие умы человечества:
https://en.wikipedia.org/wiki/Very_long_instruction_word
https://www.ixbt.com/cpu/vliw.shtml
Если совсем вкратце и на спичках, то в привычных нам процессорах со спекулятивностью каждый раз при вычислениях снова и снова выполняются множество, так сказать, оптимизаций весьма скверного кода, написанного людьми и переделанного в машинные коды всякими там компиляторами. По сути процессор постоянно и безостановочно тратит массу своего времени на исправление ошибок (включая собственных — предсказаний), хотя делает это достаточно хорошо. Из-за этого процессоры делают очень сложными. А где больше сложность, там и ошибки чаще. VLIW предполагает, наоборот, делать процессоры значительно более простыми, а вот эти самые оптимизации перенести на этап компиляции программы. Только задача эта, в целом, оказалась не по зубам человечеству. Пока. :)
вот сейчас кто-то наверняка ввернет про Эльбрус :) Хотя, если сравнивать, MIPS создавался из тех же предпосылок и там компайлер так-же отвечает за загрузку конвеера, в этом они схожи. Но похоже MIPS оказался более разумным компромисом между упрощением процессора и усложнением компайлера, потому и лучше прижился.
> вот сейчас кто-то наверняка ввернет про Эльбрус :) Хотя, если сравнивать, MIPS
> создавался из тех же предпосылок и там компайлер так-же отвечает за
> загрузку конвеера, в этом они схожи. Но похоже MIPS оказался более
> разумным компромисом между упрощением процессора и усложнением компайлера, потому и лучше
> прижился.Да я и сам чуть не проговорился, но делать рекламу бесплатно — это не по феншую. :)
>Только задача эта, в целом, оказалась не по зубам человечеству. Пока. :)Компиляторы, наделённые AI решат проблему? :)
>>Только задача эта, в целом, оказалась не по зубам человечеству. Пока. :)
> Компиляторы, наделённые AI решат проблему? :)Нет, просто "компиляторы решат". К сожалению некоторых - мир не стоит на месте.
Неверующие могут посмотреть на раст в качестве демки современных не-академ-ЯП-компиляторов и технологий или сравнить современный gcc (и его результаты) с его 15-25-30 летним предшественником.
Не думаю. Там же не интеллект на самом деле. Надеюсь, это не надо объяснять… :)
Не решат. Это задача полного предсказания всех возможных комбинаций всех входных условий. Ну или самых вероятных хотя бы. То есть всего юзеринпута, ага, всё, что сложнее хелловорлд - отдыхает.
Самому софту по идее должно быть более видней, чем процессору куда и через сколько ему потребуется тот или иной участок кода, а входные данные и процессор предугадает не сильно лучше. Но видимо придётся тогда допиливать весь софт включая ос и прикладные программы.
Предлагаешь софту меняться на лету под каждый набор x, y и z? Это займёт куда больше ресурсов проца, чем спекулятивное выполнение сразу двух бранчей.
Я предлагаю самому софту решать то за что сейчас отвечает ЦПУ. Поскольку софту виднее. Как минимум ему виднее какие участки кода и данные стоит спекулятивно выполнять и подгружать, а какие нет.
> Если совсем вкратце и на спичках, то в привычных нам процессорах со спекулятивностью каждый раз при вычислениях снова и снова выполняются множество, так сказать, оптимизаций весьма скверного кодаДело не в скверном коде. Дело в том, что оптимальный порядок исполнения зависит от входных данных. На этапе компиляции эту оптимизацию сделать никак, от слова совсем.
>> Если совсем вкратце и на спичках, то в привычных нам процессорах со спекулятивностью каждый раз при вычислениях снова и снова выполняются множество, так сказать, оптимизаций весьма скверного кода
> Дело не в скверном коде. Дело в том, что оптимальный порядок исполнения
> зависит от входных данных. На этапе компиляции эту оптимизацию сделать никак,
> от слова совсем.Скажем так: эту задачу не решить при тех практиках программирования, которые нынче в ходу.
Её вообще не решить. Потому что количество возможных вариантов входных данных для одного блока JPEG-энкодера - 16*16*(2^24). И никакие "практики" не помогут написать оптимизированный заранее вариант кода под каждый из них.
> Её вообще не решить. Потому что количество возможных вариантов входных данных для
> одного блока JPEG-энкодера - 16*16*(2^24). И никакие "практики" не помогут написать
> оптимизированный заранее вариант кода под каждый из них.Строго говоря, решение есть, но выходит за рамки одной этой архитектуры. Оно, я думаю, в гибридных архитектурах будущего. Скажем, в пределах одной вычислительной системы для быстрых вычислений, где это возможно, используется VLIW, а для «сомнительных» вычислений — какой-нибудь x86. И над всем этим отдельный сверхэкономный процессор-диспетчер, управляемый микроядром или экзоядром, который распределяет поступающие задачи по наиболее пригодных для них подчинённым процессорам для обработки.
VLIW - вообще не взлетел, и уже точно не взлетит. Проблема всё в том же, о чём я говорил выше. Компилятор генерит +/- универсальный код, но в зависимости от конкретных ветвлений (а конкретные ветвления зависят от входных данных) он внезапно оказывается либо оптимальным, либо нет.
В отличие от компилятора, CPU оперирует _законченным_ набором: код + входные данные, поэтому может делать определённые оптимизации, которые компилятору недоступны. Другое дело, что очень часто разрыв между данными и выполнением настолько мал, что, чем дожидаться окончания обработки этих данных, быстрее параллельно заранее обработать обе ветки перехода например, а потом один из результатов выкинуть.
Ну если ты сначала будешь читать переменные из памяти, а только потом выполнять операцию с ними же, то оно так и будет.
типа
a=[e]
b=[f]
c=[g]
d=[h]
a+=b
c+=h
[e]=a
[g]=c
вместо
[e]+=[f]
[g]+=[h]
то оно как бы и будет, но работать будет медленнее. посему и придумали механизм подгрузки данных в кеш заранее. Поначалу думали, что единственным побочным эффектом будет замусоривание кеша. Не думали люди, что есть любители покопаться в чужом мусорном ведре.
> Не думали люди, что есть любители покопаться в чужом мусорном ведре.Как же не думали? И думали, и знали об этом. Но, согласно городским легендам, ни Штеуд, ни вообще никто не планировал столь долгой жизни для x86. Предполагалось, что ей на смену очень скоро придут другие, _нормальные_ и полноценные (то есть спроектированные с умом, а не потому что надо что-то выбросить на рынок) архитектуры. Интел сама их несколько штук разработала, но рынок проголосовал рублём за самую худшую, временную, убогую, всю на костылях и распорках, перелатанную пластырем и всюду перемазанную зелёнкой. А всему виной оказался софт, как известно, который типа дорого переписывать, ибо время программистов, то да сё… Ну вот — что сообща приготовили, то и кушаем.
Какой-то прям исторический парадокс в наихудшем виде.
Возьму на себя смелость выдвинуть идею о том, что этот порочный круг может быть разорван только после смены отношения к программистам. Их не надо закармливать и на ручках убаюкивать, не надо платить им огромные зарплаты за писание одного и того же ненужно снова и снова на протяжении десятилетий. Программирование как таковое — это не высокая наука или искусство, а прикладная, вспомогательная, сервисная область деятельности. Компетентные, коих очень мало, пусть так и пишут важный и нужный системный софт, типа компиляторов, а все остальные пусть осваивают уже давно написанные и благополучно забытые сотни отличных прикладных программ, а если сильно горит что-то писать, то есть уйма скриптовых языков и задач реальной жизни, которые надо начинать хотя бы пытаться понимать, а не витать где-то в облаках или вообще в космосе. Однако что-то мне подсказывает, что софтверные компании будут очень против. :)
Жирно сказанно. Попробуй не заплатить программистам. Будешь тусить с железкой, которая может включаться и в биппер пищать. Ваш отличный готовый софт за месяц-два уже устарел, нужно писать новое, но мы же программистам не платим. Можете что-то на скриптовом языке или на бейсике наваять, думаю получится, что-то крутого hello world с рюшечками.
> скриптовых языковВ которых ещё больше проблем и в целом они работают медленее. И писали их всё те же "компитентные программисты" (нет). А вообще как ты можешь мне запретить писать что хочу на чём хочу? Это тебе не венда где сидят миллионы индусов и пишут вместа цикла кучу условий. Тоже, видимо, "компитентные программисты".
> сотни отличных прикладных программ
Меня ни одна не устраивает для моих задач, этого достаточно чтобы начать писать своё? По моему вполне. И плевал я на твоё мнение.
Вот гонево про "худшую". На практике самой производительной архитектурой оказалась как раз переусложнённая x86. ARM, MIPS и прочее в общих задачах прососало по производительности настолько, что в персональном/промышленном применении их никто всерьёз не рассматривает. ARM нашёл себе нишу в смартфонах и прочей эмбедовке, где Performance-Per-Watt важнее пиковой производительности, MIPS остался управлялкой в другого рода эмбедовке, вытеснив POWER, и конкурируя с ARM. Но самое-то весёлое, что x86 удалось оптимизировать и по энергопотреблению - и в итоге та же циска свои управляющие процы стала делать на x86. То есть, и ARM/MIPS вскоре в своих нишах придётся не сладко.
Всё, сдаюсь. :)Осталась самая малость до наступления светлого будущего — научиться правильно использовать кольца защиты.
да плевать вашей сиське на энергопотребление. ASR9900 в минимуме снабжена спаркой из двух блоков питания по два, что-ли, киловатта (а есть и по шесть). Где там вы процессор разглядите?Циска "стала делать" управляющие процы x86 в 2005м году, только это было специфическое железо. Догадаетесь, нет?
Вряд ли, похоже не в теме вы, как и про питание. Это была ASA. А процессор в ней был соплерон (в самых старших - уже полноценный пентиум) - и сделано это было не ради эффективного энергопотребления, а потому что китаец, отвечавший за qnx (или что это там было в pix?) помер от старости, так и не сумев написать к ней драйвер usb-портов. Зато такой драйвер был в rhel, кастрированной и очищенной от лейбаков копией которой и был снабжен новый проект.циске понравилось, новая технология начала продвигаться и в другие устройства. Но rh почему-то не хочет поддерживать мипсы. Похоже, помучавшись пяток лет с самостоятельной поддержкой, они все же решили что мейнстримная архитектура дается проще.
к тому же торговать байтиками а не сложным железом им тоже понравилось, поэтому масса "железа" нынче имеет виртуальные аналоги для вмвари и kvm. Включая, но не ограничиваясь, магистральными mpls маршрутизаторами (а то ж!) Под какой, как вы думаете, процессор? Ну и зачем тогда поддерживать еще одну, мертвенькую, архитектуру?
В младшей 5505 геоды были )
Труп итаниума уже есть, зомби-Эльбрус шевелится усилиями гос-некромантов. Больше щдураков не нашлось.Некоторые идеи красивы только на бумаге.
>Некоторые идеи красивы только на бумаге.Правильно пишете! А как дошло дело до реализации, то появились всякие спектры и мельтдауны )))
На зомбях подобное появится не может просто в силу того, что те либо мертвы, либо не нужны.
Чем тебе Эльбрус не угодил? Вполне себе решение, просто цена сейчас не адекватная.
Видно, что ребята знают что делают. Вообще думал, что в России компетентных людей в этом вопросе не осталось, а оно вон как.Я бы взял, особенно в ноутбучном исполнении. Это был бы самый неуловимый Джо из всех известных.
>Друзья, ответьте, а нельзя ли эту самую спекулятивность вынести из функций процессоров и перенести данную задачу на компиляторы, ОС и т.д. (в общем, на сам софт)?С таким же успехом прогноз погоды можна заменить подводной лодкой.
> > So why do that STIBP slow-down by default when the people who *really*
> > care already disabled SMT?
>
> BTW for them, there is no impact at all.С подвохом. STIBP не включается при запуске ведра с nosmt ключом. Можно прострелить себе обе ноги убрав HT через efi и оставив STIBP.
Линус Торвальдс молодец. Защитник, лидер и борец.
Это надо писать в 4-ре строки
Молодец. Потому что падение производительности от этого дерьмища перешло все разумные пределы. Ещё бы кто-то интелов на отзыв процов продавил, всё равно себестоимость камня - копейки.
молодец был бы, если бы самый первый, kpti патч, заставил сделать условно-компилируемым, и проверять на потери производительности в отключенном режиме.
Тогда и следующим было бы неповадно, и копипастеры из freebsd бы, может, призадумались. Но, видимо, интел очень просил такого не делать - а то ж этот тест запросто можно и другим боком повернуть.а так - увы, ни разу не молодец, когда у самого система уже совсем перестала шевелиться, после скольких там - четырех ненужнопатчей - начал "выражать озабоченность" пятым. Ну надо же, проснусо.
Беги, пингвиноид, за i9, тебя уже ждут с подставленным мешком для денег.
Nah нах, meltdown дергается банально. Спектры могли бы, да.
> Nah нах, meltdown дергается банально. Спектры могли бы, да.меня не очень беспокоит банально-дергаемая уязвимость readonly и требующая запуска тяжелого враждебного кода на моей системе - ну разьве что с этим новым знанием я буду более тщательно относиться к паролям в памяти (традиция затирать их сразу после использования мусором - хорошая, уменьшает окно, в которое их могут подобрать, но она и раньше была неплоха) и запуску браузера с банковскими учетками параллельно с каким-то другим. Но я как-то и раньше не очень это любил, поскольку можно ж обойтись и уязвимостями в js...
потери производительности от kpti в линуксах - пожалуй, максимальны из всего зоопарка - причем проявляются даже при отключенном горе-хаке.
почему-то Линуса это не беспокоило. Вероятно, на его железе ядро продолжило пересобираться за приемлемое время.
Повторяю: речь не о том что это совсем ненужный код, а о том, что в ядре миллиард вполне нужного кода, который никто практически никогда и не пытается отключать - условно-компилируем. А этот - нет.
Среди атак на HT, не все readonly. Теоретически можно и другой процесс заставить считать, что загруженное из атакуещего потока в кеш число хранится по тому же адресу, который собирается прочитать атакуемый процесс.
Не, ну то, что интел читеры относительно access latency, и в итоге говнище с обработкой прав доступа к памяти таки вылезло на свет - ежу понятно. И то, что процы с meltdown (обходом контроля RPL/CPL) надо отзывать - тоже.Задница в том, что спектр - не результат того же читерства, и пара вариантов спектра таки и на AMD работает. И их митигация тоже не копеечная.
И лучше уж уже сейчас сказать, что да, между юзерспейсами - жопа, но в эту жопу с попутным ветром долбиться не так просто, и вообще вряд ли кто будет, чем продолжать академически бороться с ветряными мельницами, попутно загоняя производительность ниже плинтуса.
Ну и про арм забыл, ад, спектр и там наличествует.
>И их митигация тоже не копеечная.МИТИГАЦИЯ. Иисусе. Ты серьёзно?
Абсолютно.
Ну кайзер в отключенном режиме в общем каши много не просит. На практике отличить от погрешности не получилось.
> Молодец. Потому что падение производительности от этого дерьмища перешло все разумные пределы.
> Ещё бы кто-то интелов на отзыв процов продавил, всё равно себестоимость
> камня - копейки.Копейки копейками, но не отзовут из-за неминуемого создания прецедента. Одно дело ошибка, например, в арифметике, делающая процессор непригодным для использования по назначению, когда надо менять или возвращать деньги с возмещением убытков, но совсем другое — _чужая_ безопасность, которая для большинства людей очень эфемерна и сродни пугалкам из телевизора, а специалистов по безопасности традиционно никто не слушает, пока не станет поздно, но тогда уже не до специалистов. Особенно, если весь класс изделий, все 100 процентов продукции за много лет не соответствуют требованиям обеспечения чужой безопасности. Неужели отозвать? :) На это пойтить никак нельзя! “S” in Intel stands for your security! Накатите наши спасительные патчи и приходите в магазин за новыми процессорами производства Intel с улучшенными ценниками.
Ну вот потери от смещения Amazon например в сторону AMD могут оказаться тоже не маленькими.
Не знаю, да, что выйдет дешевле, не плавал.
> Ну вот потери от смещения Amazon например в сторону AMD могут оказаться
> тоже не маленькими.
> Не знаю, да, что выйдет дешевле, не плавал.С чего бы там быть потерям? Для большинства задач у процессоров Интела нет какого-то явного преимущества, чтобы делать людям погоду.
Потери-то не у амазона :)
А давайте просто все забудем про эти уязвимости. А кто вспомнит - тому глаз вон. А то и оба. И руки по локти. И в яму. И будем жить-поживать как раньше.
Нет уж.
И так сойдет. (c)
Но у меня вопрос. Если я отключил HT в BIOS, то есть, вот было у меня 4 ядра и 8 каналов - стало 4 и 4, то этот патч, если он уже присутствует в firmware пакете Линукс или в винде где-то у неё там, всё равно будет замедлять мой процессор?
Ты хотел сказать "потоков"?
Если отключения при отсутствии HT не досыпали - да, будет. Для L1TF вроде досыпали. Для STIBP - х его з.
Машина с CPU Intel под Haiku OS подвержена уязвимостям Spectre/Meltdown, или нет?
> Машина с CPU Intel под Haiku OS подвержена уязвимостям Spectre/Meltdown, или нет?Exploit == эксплуатация.
Уязвимость сама по себе подобна самураю с мечём, но только без меча.
Машина с CPU Intel подвержена двум этим типам уязвимости под любой ОС. Насчёт наличия программных затычек в конкретной ОС - к документации ОС.
