Группа исследователей безопасности, из которых трое (Daniel Gruss, Michael Schwarz, Moritz Lipp) участвовали в выявлении первых уязвимостей Meltdown и Spectre, опубликовали (https://twitter.com/lavados/status/1062538140894855169) сведения (https://arxiv.org/pdf/1811.05441.pdf) о семи новых атаках, затрагивающих механизм спекулятивного выполнения инструкций современных процессоров. Возможность проведения атак протестирована на CPU Intel, AMD и ARM. Две новые атаки являются вариантами уязвимости Meltdown (Meltdown-PK для CPU Intel и Meltdown-BR для Intel и AMD), а оставшиеся пять представляют собой варианты уязвимости Spectre (применимы для Intel, AMD и ARM). Для всех семи атак подготовлены работающие прототипы эксплоитов.
Как и ранее выявленные уязвимости данного класса новые проблемы основываются на создании условий для спекулятивного выполнения определённых операций, результат которых отбрасывается процессором после определения неудачного прогноза, но следы выполнения оседают в общем кэше и могут быть восстановлены при помощи методов определения содержимого кэша по сторонним каналам, анализирующих изменение времени доступа к прокэшированным и не прокэшированным данным. Успешное проведение атаки, в зависимости от вида утечки информации, позволяет определить содержимое памяти сторонних процессов, ядра и виртуальных машин, что может использоваться в многопользовательских системах, например, для извлечения ключей шифрования или конфиденциальных данных.
Выявленные проблемы класса Meltdown (позволяют получить доступ к памяти приложений других пользователей, операционной системы и виртуальных окружений):
- Meltdown-PK - атака проявляется только на CPU Intel и позволяет обойти ограничения, установленные при помощи ключей защиты памяти
(PKU, Protection Keys for Userspace). В обычных условиях попытка доступа к области памяти с неверным ключом приводит к генерации исключения. В ходе спекулятивного выполнения инструкций выполняется фактический доступ к содержимому памяти и результат в случае несоответствия ключей отбрасывается, но прочитанное значение оседает в кэше;- Meltdown-BR - атака проявляется на CPU Intel и AMD и связана с утечкой данных после спекулятивного выполнения инструкций проверки границ, определённых в расширении MPX (Memory Protection eXtensions). При попытке доступа к области памяти, вне определённых при помощи MPX границ, возможно создание условий для спекулятивного обращения к памяти, результат которого будет отброшен после определения ошибки доступа, но осядет в кэше.
- Исследователи попытались разработать ещё шесть Meltdown-подобных атак, манипулируя исключениями, возникающими при делении на ноль, некорректном выравнивании памяти, превышении лимита на число сегментов, нарушении защиты SMAP (Supervisor mode access prevention), выполнении некорректных объектных кодов и манипуляции с областями памяти, в которых запрещено выполнение кода. Данные попытки не увенчались успехом.
Выявленные проблемы класса Spectre:
- Spectre-BTB-SA-IP, Spectre-BTB-SA-OP - два новых варианта атаки на буфер предсказания ветвления (BTF, Branch Target Buffer). Атаки создают условия для влияния на состояние блока предсказания переходов с целью совершения целенаправленного спекулятивного косвенного перехода, после которого считанный из памяти адрес перехода (искомые данные), остаётся в кэше. Атаки позволяют получить доступ к памяти приложений только в рамках привилегий одного уровня, например, для атаки на браузеры, sandbox-окружения и системы совместного изолированного выполнения кода. Проблемам подвержены CPU AMD, ARM и Intel.- Spectre-PHT-CA-OP, Spectre-PHT-CA-IP, Spectre-PHT-SA-OP - три варианта атаки с использованием таблицы с историей шаблонов переходов (PHT, Pattern History Table). Spectre-PHT-CA-OP позволяет получить доступ к произвольным областям памяти, а Spectre-PHT-CA-IP и Spectre-PHT-SA-OP ограничены доступом к памяти в рамках привилегий одного уровня. Проблемам подвержены CPU AMD, ARM и Intel.
По заявлению (https://software.intel.com/security-software-guidance/api-ap...) компании Intel все из упомянутых в отчёте уязвимостей могут быть блокированы с использованием уже применяемых для Spectre и Meltdown методов защиты (производители процессоров и операционных систем были заранее уведомлены о проблемах).
URL: https://twitter.com/lavados/status/1062538140894855169
Новость: https://www.opennet.ru/opennews/art.shtml?num=49608
И куда бежать?
Эльбрус
ZX-Spectrum и то быстрее, дешевле и доступнее
> ZX-Spectrum и то быстрее, дешевле и доступнееПредъявите.
> Предъявите.Кокаинум.
Не в тему, но спрошу: Михаил, вы ли это на видео?
https://www.youtube.com/watch?v=8rYfUO1x_MQ
Слайд "по итогам импортозамещения":
Было: Cisco, Nortel
Стало: РусьтелетехА далее по цепочке:
https://rusteletech.ru/uncategorized/partners/ прямой ссылки нет, идем на сайт марвеллайн по ссылке в почте http://rusmarveline.ru/. Получаем:
"Сайт на обслуживанииИзвините, сейчас наш сайт закрыт на ремонтные работы. Загляните чуть позже, спасибо. Мы ценим ваше терпение."
Отличное импортозамещение! "Молодой человек, Вы что не видите? У нас обед!"
По аватарке в начале видео не удалось идентифицировать?А так даже удивился - на видео мямлит, а на опеннете храбрый воен такой.
> Не в тему, но спрошу: Михаил, вы ли это на видео?
> https://www.youtube.com/watch?v=8rYfUO1x_MQДа. Правда, невыспавшийся совсем -- слайды поздно закончил рихтовать.
> Правда, невыспавшийся совсемНормально. Как раз обновим твои фото на "Мироточце". :-)
>> Правда, невыспавшийся совсем
> Нормально. Как раз обновим твои фото на "Мироточце". :-)Да сколько влезет -- на Суде встретимся, вот тогда и цена всему будет.
Не, ну спектрум реально дешевле, кто будет спорить?
> Не, ну спектрум реально дешевле, кто будет спорить?Его как минимум купить реально, без NDA. И даже компиляторы с открытыми исходниками под него бывают. И прочие инструменты, типа дебагеров/эмуляторов и проч.
ZX-Spectre
С удовольствием бы, да вот засада: в рознице не попадаются...
Розница - это когда винда ставится?
Это когда мозги по полгода не трахают а потом не кидают с понтом "извините, всё юрикам распродали, но вот в следующий заход - вот прям обязательно!"
Не куплю, даже если в рознице будет, пока не будет его поддержки в GCC.
А вы как думаете программы под него собирают? GCC и пачка системных библиотек давно уже портированы. Вовсю в Quake 3 бегают.
> А вы как думаете программы под него собирают?LCC.
> GCC и пачка системных библиотек давно уже портированы. Вовсю в Quake 3 бегают.
Вы совершенно случайно не с pavlinux работаете? :)
Их собственный lcc вроде как gcc-подобный. Насколько я в курсе, только некоторые расширения не поддерживаются, но, раз ядро собирается, значит некоторые!=все.
Когда Эльбрус будет также популярен (пофантазируем!!!), как Intel, AMD, ARM, то его тоже будут упоминать в отчётах об уязвимостях не реже и материть точно так же, как и вышеупомянутую троицу.
Тут я бы скорее предсказал вариант "В" (B is for Bitrix).
Продукт получает довольно широкое распространение исключительно в России вследствие нетехнических методов продвижения.
Исследователи безопасности о нем говорят мало, поскольку заграничным он не впился, а наши не хотят связываться, озвучивая свои изыскания публично.
Поэтому матерят продукт часто, но в основном те, кому приходится с ним работать.
> наши не хотят связываться, озвучивая свои изыскания публично.
> Поэтому матерят продукт часто, но в основном те, кому приходится с ним работать.Т.е. кладут на свой персонал (ну, и на себя, соответственно)?
> Когда Эльбрус будет также популярен (пофантазируем!!!), как Intel, AMD, ARM, то его
> тоже будут упоминать в отчётах об уязвимостях не реже и материтьты у меня доупоминаешься!
> точно так же, как и вышеупомянутую троицу.
материть можешь - но шопотом. И только внутри рабочего помещения.
> ты у меня доупоминаешься!И чего в итоге? Вы будете делать вид как все секурно, пока вас тихо но мощно имеет во все щели Equation? Давайте и безопасность в айти отправим туда же куда авиамоделизмы всякие.
Если что - профессионалы от хака о своей деятельности не вопят. Они тихо приходят, оттрахивают все живое, уносят все что удалось найти и беспринципно извлекают из этого максимум. И вообще-то очень хорошо и полезно, если громкие вопли случатся ДО того как случится ЭТО. Это хоть как-то сподвигает потенциальных адресатов атак быстренько устранить проблему. Если повезет то ДО того как раздуплятся профессионалы.
> материть можешь - но шопотом. И только внутри рабочего помещения.
Товарищ майор, так потом ты же и будешь в добровольно-принудительном порядке жрать это самое. А остальным этот автоТАЗик не больно нужен, так что они купят себе интел да китайско-тайваньское.
Так что кирпич вместо мобильника будет у товарища майора. У остальных будет какое-нибудь ксяомяо скорее :)
Опасно, программисты запинают за такое предложение. А после попыток заняться оптимизацией кода под потоковую обработку так и вообще предадут анафеме )
> ЭльбрусС проприетарным компилером, приватными репами и NDA при покупке? Интел конечно г@вно, но как видим это далеко не предел скотства - есть рекордсмены покруче.
VLIW?
Да, Эльбрус.
https://riscv.org/ ?
Ну если верить этим ребятам, что их архитектура свободна от проблем с Meltdown и Spectre. Будем налеяться, что это так и что взлетит.
Она от них свободна только потому, что свободна от соответствующих фич, которые позволяют эти атаки реализовать. <тут картинка с негром, прикладывающим палец к голове>: у вас не будет проблем с meltdown и spectre, если нет спекулятивного выполнения инструкций.
MISC Forth-процессоры
Языкоуровневые процессоры не взлетят. Java-процессоры это уже показали.
в перспективе на risc-v
сейчас они начинают потихоньку arm-ы двигать
[ http://www.cnx-software.ru/2018/11/02/%D0%BA%.../ ]
На arm. Множество нетоповых arm неуязвимы (например arm A53 и A55) для старых версий атак. Там похоже нет спекулятивного исполнения. Так чтои ноавн версии атак скорее всего мимо. Большая часть нетоповых телефонов будет неуязвима. И кучи одноплатных arm типа raspebery pi3 и odroid c2 тоже.
https://developer.arm.com/support/arm-security-updates/specu...
То есть ты, анон, даже доподлинно не знаешь, есть ли в армах спекулятивное исполнение, но советуешь другим туда бежать? На одноплатные игрушки, ой-вэй!
Т.е. тебе, гебист, дали ссылку, в которой описана ситуация с армами в плане атак по каналам "Cache Timing Side-Channel Mechanism", но ты ее читать не собирался и сразу выдал своё экспертное мнение? Или встал в позу "не верю!"? Там специально для таких ленивых, как ты, написали "Only affected cores are listed, all other Arm cores are NOT affected" причем "all other Arm cores are NOT affected" выделено жирным. В списке нет A53 и A55. Там же, в начале статьи более обще/расплывчато написано "The majority of Arm processors are not impacted by any variation of this side-channel speculation mechanism. A definitive list of the small subset of Arm-designed processors that are susceptible can be found below". Причем "not impacted" также выделено жирным. Или ты думаешь, что в A53 таки тайно запили внеочередное выполнение команд, но нас обманывают? Пришлось отдать на растерзание всякие A76/75? Ты в очередной раз подтвердил что ты балабол.
Какой гиперактивный аноним. Не понимает прочитанное, но дерзко бросается атаковать врага!
> Какой гиперактивный аноним.Как ты критично о себе отзываешься!
Друх, это не главный и даже вообще не повод куда-то "бежать", других хватает))
Никуда. Скорее всего опять будет нужен физический доступ к компьютеру.
Который имеется у любой странички в браузере. И у всех приложений. Ок.
Можешь привести несколько примеров, когда атаки "на механизм спекулятивного выполнения в CPU" были выполнены и от этого кто-то пострадал?
На sh-2 от хитачи вроде не было всей этой спекулятивщины, да и на sh-4 тоже. Хорошие актуальные процессоры. Такими темпами скоро сравняются с современными.
имел комп на sh-3 под winCE, по скорости чуть шустрее 486ой машины. но это было в 1997ом...
> И куда бежать?если параноик то выключить SMP (в ущерб потери производительности) как это сделало OpenBSD или тупо забить на все это и использовать процессоры.
используемые по сей день компьютерные процессоры, SoC'ы все равно содержат известные и неизвестные ошибки.
"манипулируя исключениями, возникающими при делении на ноль"
Так и знал шо это закладка внедрённая в школах.
Что-то мало, всего-то семь. Когда будут анонсы сразу по двадцать хотя бы?
- x86, когда уже на покой?
- Только вместе с MS.
- Сладкая парочка Wintel, ешь не задумываясь!
это все понятно,
но современная блотварь (браузеры, игры и т.д.) тормозит на всем, что не современный х86. ну разве что power от IBM может еще ничего по мощи...но он и стоит как самолет.
> ну разве что power от IBM может еще ничего по мощи...
> но он и стоит как самолет.Хренассе "ничего", Вы вообще в курсе, куда получается двухсотгигабитные интерфейсы втыкать? (нет, на x86 таких шин пока будто не завезли)
Гонишь дядька. PCI-e gen4 отлично в x86 втыкается, и прокачивает 200Gbit/s тоже (медленно намекаем на Mellanox HDR).
100Gbit/s в старые несчастные PCI-e gen3 + прокачать столько же через диски что бы отдать в сеть, без этого 200 Gbit/s сети можно и раздать на старых Mellanox EDR / Intel OmniPath.Если ты о шинах Эльбруса - то помнится раньше Багетовцы втыкали эту шину куда не лень. в x86 тоже.
Шикарно, дабы ты не прослыл треплом, давай-ка, озвучь нам тут ШТЕУД проц с поддержкой PCIe gen 4...
А втыкать gen4 в gen3 для чайников предусмотрел производитель, и Mellanox сюда приплетать не надо. Последний полный Offload и CPU напрямую не нагружает.
Еще по теме, можно будет здесь запостить: https://www.networkworld.com/article/3321036/data-center/gpu...
ну браузеры и сайт сейчас тоже крайне блевотные, тормозят и на современном железе. новый гмейл например.
> ну браузеры и сайт сейчас тоже крайне блевотные«имел её рука»
> power от IBM может еще ничего по мощи...но он и стоит как самолет.Power-ы сейчас дёшево. Дешевле чем штеудо-gовно.
18-ядерный SMT4 стоит ~$1.4K в розницу.
Никогда. Под x86 есть ещё и огромный слой ISA (не путать с шиной с таким названием), которую заменить будет очень трудно.
ISA -- Instruction Set Architecture. Это и есть тот набор команд, из которого состоит исполняемый код. Описан в мануалах, которые можно свободно скачать с сайтов всех разработчиков процессоров (за вычетом МЦСТ). Ниже ISA лежит микроархитектура.
В данном случае я конечно имел в виду Industry Standards Architecture, но не шину, а именно сам факт. Если надо новую плату запилить под новый комплекс АРМ, что мы делаем? Правильно - берём PCI-e development board и шлёпаем PoC, после чего доводим до ума и пускаем в мелкосерийное производство. Ну и 99% серийного консамерского железа разрабатывается под x86-совместимые системы.
А драйвера к этой нашей новой плате будут либо под Linux/x86(-64), либо под винду, со всеми вытекающими. Заниматься мазохизмом адаптации софта к infinitely vast space of например ARM-платформ, каждая из которых не совместима с остальными - лениво, делать вендор-лок под одно конкретное поделие на другой платформе - чревато.
> А драйвера к этой нашей новой плате будут либо под Linux/x86(-64), либо
> под винду, со всеми вытекающими.АМДшные открытые дрова для видях под линя народ запускал на как минимум ARM, MIPS и PPC. Да и остальные pci-e, usb, ... дрова должны работать независимо от того какая там архитектура.
А адаптация - да какая у pci адаптация? PCI девайс и есть pci девайс. Там не так уж и важно какой процессор на стороне хоста, лишь бы регистры програмил правильно и данные кидал.
А, да, я беспроводную сетевку от атероса на мипсе запускал. Вот буквально собрал ядро и включил драйвер - и все завертелось. Драйвер pci там конечно какой-то платформоспецифичный, но драйверу сетевки все это не видно, ему вывешен все тот же pci, он програмит регистры так же как обычно. И все работает. А будет там ARM или PPC - драйвер контроллера pci конечно свой будет, но драйверы pci устройств останется те же самые...
-BR - это не мелтдаун, а вариант спектра. Суть мелтдауна в cross-CPL.
А Intel Itanium подвержен впринципе таким атакам?
Мёртвые не потеют.
Говорят волосы у них продолжают расти
Нет. Но много разных других «но». Скажем, если б Итанику хотя бы уполовинить энергопотребление, то у него был бы шанс.
тИтаник было не спасти с самого начала, а айсбергом вылетела попытка заменить комбайн снегоуборщиком. Так же, как и с прочими VLIW
Трудности с VLIW обусловлены, как мы знаем, не самим VLIW, а прежде всего тем, что эта архитектура заведомо не подходит общепринятому циклу производства софтверного г-на для копроэкономики. Чисто гипотетически, если убрать x86 и орды г-нокодеров, пишущих всякое нeнyжнo под него, то для оставшихся вменяемых и разумных программеров нашлось бы чем заняться для машин с VLIWом в пузе.Я бы для себе экспериментов купил у работодателей шигорена пару эльбрусов, но по цене не более 5 тыр. за штуку плюс ещё 5 тыр. за двухсокетную плату. :)
> ...пишущих всякое нeнyжнo под него, то найдётся такая же куча программистов которая будет писать всякое ненужно под VLIW.FTFY
В целом с тобой согласен. Самые распространённые процессоры просто оптимизированы под некачественный код, который нужно предсказывать чтобы побыстрее выполнять. Экономят деньги на квалифицированных программистах и времени разработки программ за счёт усложнения процессоров.
> В целом с тобой согласен. Самые распространённые процессоры просто оптимизированы под некачественный
> код, который нужно предсказывать чтобы побыстрее выполнять. Экономят деньги на квалифицированных
> программистах и времени разработки программ за счёт усложнения процессоров.Ага. Только нынче некуда растить частоту, как было можно в девяностых, покрывая тогдашний детский шлак увеличением чистой производительности железа. Следовательно, вал г-нокода неминуемо затопит нас. Ребятки с программной логикой на отступах всё порешают. :)
> Ребятки с программной логикой на отступах всё порешают. :)Хаскелисты/Мирандисты и F#-сты готовят диверсию?
А чего не пихонеры?
> В целом с тобой согласен. Самые распространённые процессоры просто оптимизированы под некачественный
> код, который нужно предсказывать чтобы побыстрее выполнять. Экономят деньги на квалифицированных
> программистах и времени разработки программ за счёт усложнения процессоров.Код на этом уровне качественный. Тем более что часто генерируется компиляторами. (которые сами всё что нужно и можно предсказывают причём на основе гораздо более обширного анализа программы)
говно-компилятором gcc обусловлены проблемы итаниума - каждый кто глянет тот код который генерил gcc для ia64, сойдет с ума. 2/3 бинарника это NOP.
странно, что гуанокомпилятор gcc не создал ни малейших проблем для ix86 - хотя во времена доступности итаниумов генерил точно такой же дрянной код и для них, чем и вызвал к жизни кучу клонов - pgcc, egcs и т п - которые хоть что-то умели оптимизировать (тоже плохо).и да, где же были прекрасные компиляторы от intel и ibm?
> и да, где же были прекрасные компиляторы от intel и ibm?По какой-то непостижимой причине IBM не была заинтересована в успехе Итаниума. Вот ведь странно, да? :)
Ну а Штеуд это печаль. Руки-крюки и все растут из того места, что ниже спины сзади. Процессоры делать научились, а софт писать -- увы. Итаник это уже по меньшей мере третья перспективная архитектура, которую они успешно проторговали лицом из-за неумения хорошо писать сложную малварь для собственного железа. Вплоть до того, что для широко известного шпионского чипа им софт предоставил добрый дедушка Танненбаум, а жабку -- всякие сторонние сантехники. Не, ну не всё так ужасно, ибо действительно мало кто способен хорошо писать сложный софт. Штеуд в целом справляется, особенно если не забывать про дрова для встроенного видео и закладки^W дрова для сетевых карточек. Это, безусловно, успех. Громкий и всемирный.
Интеловский компилятор, традиционно, не бесплатный. Отсюда и проблема итаника с софтом. Но по качеству кода он уделывал и уделывает gcc. Так что с фраза про то что интел не умеет писать софт - точно мимо.
а все деньги горе-разработчиков потрачены на сам итаник, на компилятор уже никак не наскрести.gcc какбе никогда и не было о качестве кода (а когда началось, его начали старательно портить), оно было о "затобесплатно" всегда и во всем (ну и еще "зато работает", что, скажем, для сановского родного компилятора было верно только местами и временами)
так что итаник потопило что-то другое. Наверное, проклятая майкрософт? Хотя, нет, они же поддерживали его сколько могли, в отличие от других утонувших платформ, кстати.
> gcc какбе никогда и не было о качестве кода (а когда началось,
> его начали старательно портить), оно было о "затобесплатно" всегда и во
> всем (ну и еще "зато работает", что, скажем, для сановского родного
> компилятора было верно только местами и временами)Нуу ещё про gnu extensions, будем честны.
> так что итаник потопило что-то другое. Наверное, проклятая майкрософт?
> Хотя, нет, они же поддерживали его сколько могли, в отличие от других утонувших
> платформ, кстати.Они не могли сделать свои драйвера для печати архитектурнонезависимыми. И сподвигнуть всех важных поставщиков принтеров поддержать ia64 (либо сделать это за них) -- тоже.
Ну, "по некоторым данным из траншей".
Во-первых, не всегда.
А во-вторых, icc даже не не всегда все SPEC CPU может скомпилировать, не говоря уже про все остальное.
По правде говоря, icc никогда не был general purpose компилятором.
> 2/3 бинарника это NOP.Ну вот кагбе да, это впечатляет.
Впрочем, у Итаника ещё и проблема с жором электричества и тепловыделением. Две такие проблемы вместе совершенно неприемлемы, хотя по отдельности ещё как-то можно было бы стерпеть.
да вроде на вторых итанах это порешали.
> да вроде на вторых итанах это порешали.Не сильно и порешали. Все камни с тепловыделением сильно за 100 Вт. Эконом-класса нет вообще. Кому так сильно надо, что готовы платить по счётчику много денег, те и такое купят, а больше никто.
Мы сейчас точно про серверные камни говорим?
> Не сильно и порешали. Все камни с тепловыделением сильно за 100 Вт.
> Эконом-класса нет вообще. Кому так сильно надо, что готовы платить по"представительское жилье эконом-класса" бывает только в агитках рюйских риэлторов.
Если тебе нужна мощная числодробилка - довольно глупо искать ее "эконом-вариант", да еще и удивляться, что никто не бежит с предложениями.
другое дело что применимость этих кипятильников даже для голой считалки недостаточно обоснована, а для чего другого так и вовсе нет ее.
> Я бы для себе экспериментов купилТо есть нихрена не имеешь, зато утверждаем про устрицы, что:
> Трудности с VLIW,.. как мы знаем,..., архитектура заведомо не подходит,...Даю 1000$, что ты даже на x86 ассме, без копипасты с гугла, Hello World не осилишь, какой впесту VLIW.
...> если убрать .. орды г-нокодеров
Самокритика, похвально!
Ай, да неужто?
Чтобы VLIW хорошо/быстро работал, ему надо набивать слоты хотя бы процентов на 60-70.
Не все задачи обладают достаточным внутренним параллелизмом для этого.
> Не все задачи обладают достаточным внутренним параллелизмом для этого.Зато уж если есть/помогли -- потенциально просматривается и выход одного потока за одно ядро.
Увы, это так. Трудности VLIW обусловлены тем, что это сферическая архитектура в вакууме, практическая оптимизация под которую - трэш и адуха.
> Увы, это так. Трудности VLIW обусловлены тем, что это сферическая архитектура в
> вакууме, практическая оптимизация под которую - трэш и адуха.
.L6:
{
adds,0,sm 0x0, 0x1, %r5
adds,1,sm 0x0, 0x1, %r6
return %ctpr3
}Чо видим? Два константных сложения 1 + 0, помещаются в %r5 и r%6,
Наверно проще загрузить две константы сразу в r5, r6?
ldw,0 0x1, %r5
ldw,1 0x1, %r6
Это аццки сложно? 1 минута ушла на поиск.
А теперь что-нибудь повеселее. Например кодек H.264.
На сколько в этот раз урежут производительность?
Не знаю, на сколько в этот раз, но после последних vX спектра и l1tf в довесок производительность хост-нод Xen просела на 40%...
"после последних митигаций"
Нечем людям заняться
Аффтарам неплохо бы конечно было хонорить исходные документы по Meltdown/Spectre и не пытаться смешивать классы атак. Классификация в статье совсем уродская.Правильно так:
В Meltdown дело не в отложенном исполнении команды, как пытаются гнать аффтары, а в пересечении базовой изоляции уровней привилегий - CPL в случае x86.
Spectre же - целый класс side-channel атак в пределах CPL, так или иначе связанных со спекулятивным выполнением команд. В которую эта пачка "новых молодёжных мелтдаунов" прекрасно укладывается.
>>По заявлению компании Intel все из упомянутых в отчёте уязвимостей могут быть блокированы с использованием уже применяемых для Spectre и Meltdown методов защиты (производители процессоров и операционных систем были заранее уведомлены о проблемах).Whitepaper:
We verified whether we can still
execute our newly discovered Meltdown-type attacks on a
fully-patched system. Even with all mitigations enabled, we
were still able to execute Meltdown-BR, Meltdown-PK, and
Meltdown-RW. These results indicate that current mitiga-
tions only prevent Meltdown-type attacks that do not cross
the current privilege level.Опять кто-то врёт.
Тут скорее не "куда бежать от уязвимостей", а "куда бежать от принудительных патчей от этих уязвимостей".90% юзеров плевать на эти уязвимости. А вот когда скорость стала просаживаться заметно - другое дело. При чем везде. Особенно заметно когда работаешь сразу во многих программах. Пока спасает nopti ядру, а вот с Виндой похуже.
Да пусть исправляют дыры. Компьютеры стали слишком быстрые. Может теперь больше начнут заботиться о том, чтобы писать чуточку более эффективный софт, а то у разработчиков как известно топовые пекарни.>Особенно заметно когда работаешь сразу во многих программах
а вот это похоже на фантазии.
В венде вроде как отключается, но производительность падает очень сильно.
> Может теперь больше начнут заботиться о том, чтобы писать чуточку более эффективный софт, а то у разработчиков как известно топовые пекарни.Точно. 640 Кб хватит всем.
Когда браузер начинает жрать по 4 гигабайта памяти на одной вкладке начинаешь задумываться...
> Когда браузер начинает жрать по 4 гигабайта памяти на одной вкладке начинаешь
> задумываться...Когда такое происходит, задумываться уже поздно, а пора брать в руки ружжо и мачете и загонять г-нокодеров на фабрику для утилизации.
Ссылочку на такую страничку, чтоб вкладка столько жрала можно?
> Компьютеры стали слишком быстрыеВыкинь свой и используй вместо него счеты и диапроектор. Докажи свои слова делом!
Этим исследователям безопасности счеты дай, они и их сломают.
для винды тулза сто лет как есть
> куда бежать от принудительных патчей от этих уязвимостейА если просто не устанавливать эти патчи, не?
> А если просто не устанавливать эти патчи, не?Тогда постепенно станешь майнером коинов. Правда, майнить будешь на чужой кошелек, это уж увы.
nopti nospectre_v2 nospec
> nopti nospectre_v2 nospecinit=/sbin/halt
> nopti nospectre_v2 nospecпадение производительности, к сожалению, уменьшится, но никуда не девается.
К тому же это ты в линуксном ведре отключил. Теперь давай в qemu/kvm (мне плевать кто там на ком стоял, давай результат), xen, обоих, и 0 и U, virtualbox. Все они необратимо изуродованы якобы-безопасными патчами.Браузер уж хрен с ним, можно оставить, все равно меньше тормозить они не будут.
> падение производительности, к сожалению, уменьшится, но никуда не девается.Возможно, но на моих задачах в пределах погрешности измерения.
> Теперь давай в...
Kvm у меня там, где производительность некритична, остальное не использую.
ну так у гугля вон и с включенным - в пределах...
во всяком случае он так меряет.> Kvm у меня там, где производительность некритична
ну вот везет. А остальным-то куды бечь от этой "заботы" разработчиков (всего!) ниасиливших #ifdef ?
в том же ядре - миллионы ненужно-настроек, обычно никогда и никем не трогаемых (впрочем, половина вообще никому, кроме автора, может быть, непонятно, для чего и как работает). А тут - -30% к производительности - и нет, никак в условную компиляцию нельзя.
Ну вот кстати да, задолбался выключать. Выключи в гипервизоре, потом во всех хост-системах. На клиентсайде никуда не денешься, а вот на внутренних системах все эти митигации нахрен не нужны. Кто бы нашептал апстриму сделать одну крутилку навроде x86_all_mitigations=off...
> Кто бы нашептал апстриму сделать одну крутилку навроде x86_all_mitigations=off...кто бы нашептал апстримам прочитать наконец главу K&R "директивы препроцессора", и выкинуть все это из исполняемого кода нахрен, а не проверять миллион kernel tunables в самом тяжелом месте контекст-свитчера (впрочем, у линукса там похоже не только миллионы проверок ненужного ненужно, а и часть кода все равно исполняется, не смотря на "отключение" - иначе сложно объяснить, откуда такие потери даже при отключенном)
все равно с уходом редхат куда-то в облачные дали технология "один дистрибутив- одно ядро" вместо слакварьской игры 92го года "выбери из трехсот одно подходящее" тоже безвозвратно утрачена.
Да, выключение != возврату производительности на место к старым версиям ядер. Но по крайней мере на 90%...
> tunables в самом тяжелом месте контекст-свитчераЧувак, ты видел набор регистров FPU и SIMD хотя-бы? На этом фоне tunables не такие уж ужасные :)
Сейчас пока так, пока новых не накрутили:nopti nospectre_v2 nospec_store_bypass_disable no_stf_barrier pti=off spectre_v2=off l1tf=off spec_store_bypass_disable=off stf_barrier=off
Для Xen тоже да, есть:
xpti=0 spec-ctrl=no-xen pv-l1tf=0
Дублируются (no) и (=off) потому, что в разных версиях ядер по-разному сделано.
> Сейчас пока так, пока новых не накрутили:мать-мать-мать...
> Для Xen тоже да, есть:а для kvm ? ;-) Ну, или qemu, я опять не пойму кто там на ком стоит.
интересно, а какой лимит у кернельной командной строки? Включая и встроенный в grub, подозреваю, он первый кончится.
> а для kvm ? ;-) Ну, или qemu, я опять не пойму
> кто там на ком стоит.А ничего что Xen это таки отдельный гипервизор, который сам ресурсы менеджит на низком уровне, а в случае kvm - это линуксное ядро хоста делает?
Впрочем настолько разбираться в системной архитектуре используемых инструментов великому специалисту по всему и вся конечно же лень.
> интересно, а какой лимит у кернельной командной строки? Включая и встроенный в
> grub, подозреваю, он первый кончится.Так он кончится только у извращенцев которым пофиг на то что их кредитки-пароли стырят и майнеров понаставят. Это даже большинству хостеров впадлу, потому что кастомеры потом чем-то недовольны оказываются. Так что они поскрипят да и удовольствуются на 5% меньше производительности. Ну и клиенты получат на 5% меньше за ту же сумму, это уж увы.
Ну на хостинге собственно PTI выключать - да, стрёмно. А вот на серверах БД того же кластера хостинга - почему нет?
а че без модного сайта в этот раз?
Spark же
Spark - это если ножницы в розетку сунуть. А архитектура называется SPARC, и она скорее мертва, чем жива.
Как интересно однако.
1. Внезапно обнаружили уязвимости.
2. Выпустили патчи, которые люто рубят производительность.
3. Намекнули что в новых процах всё пофиксено.
4.Где-то тут должен быть profitЯ никогда не был сторонником теории заговоров, но тут что-то явно не так :))
А между тем слышим про проблемы у того же интела.
> 4.Где-то тут должен быть profitНе здесь, а там. Нам не просто не говорят, где.
22.10.2018 18:47
Акции компании AMD за сегодняшний день выросли почти на 7%. Это при том, что
последнюю неделю они постепенно теряли в цене.[...]
Что касается акций самой Intel, на них слухи пока никак не отразились.
03.10.2018 15:36
К слову, акции AMD на фоне роста акций Intel упали в цене более чем на 8%, опустившись ниже 30 долларов за акцию.
> Я никогда не был сторонником теории заговоров, но тут что-то явно не
> так :))
> А между тем слышим про проблемы у того же интела.Плохой пияр - тоже пияр.
То что весь рынок вырос это конечно пофиг. Экономисты хреновы.
И нашли уязвимости специалисты из Google? Компании, которая за мзду малую подскажет -- где можно новыми камнями прибарахлиться.
Так приятно наблюдать за истерикой параноиков. Они-то, бедняги, верили, что бывает абсолютная безопасность, и тут такой удар по яйкам))
нехорошо смеяться над больными людьми
Здесь все инженеры и понимают, что абсолютного ничего нет. В технике надёжность определяется с помощью вероятностей.
> Здесь все инженерыВот так насмешил
> В технике надёжность определяется с помощью вероятностей.Ты точно инженер?
А что вас удивляет? Посмотрите хотябы статью "Надежность" на вики, раздел "Теория надежности".
Всё идет к тому, что механизмы обеспечения безопасности в итоге полностью нивелируют преимущества спекулетивного выполнения команд.
Все идет к тому, что производители процессоров хотят еще больше денег ("покупайте самые новые процессоры, в которых этих уязвимостей нет")..
Ждем очередных "улучшений", после которых процессоры будут работать на N% медленнее, но нас будут уверять, что "все делается для нашего же блага"..Непонятно только одно - еще остались такие люди, которые верят, что аппаратную (читай - в "железе") "закладку" (будем называть вещи своими именами) можно исправить программно и после этого оборудование будет работать с той же мощностью? Ведь если на машине не будет колеса, а на его месте будет картонка с нарисованным колесом, то она (машина) не поедет же от этого быстрее или хотя бы с такой же скоростью?
>что аппаратную (читай - в "железе") "закладку" (будем называть вещи своими именами) можно исправить программно и после этого оборудование будет работать с той же мощностью?Да, верю, что будет работать с той же мощностью энергопотребления!
Кто-то как сидел на неких Sparc-ах, под дружное улюлюканье и пальцем у виска кручение всех, у кого "интель рвёть как тузик грелку и стоит дешевле", так и продолжает сидеть на этих самых Sparc-ах, посмеиваясь над доулюлюкавшимися шпециолиздами.
Лет 10 назад тестировали спарки. То, что удавалось собрать их компилятором (nginx, скажем), летало, но собиралось далеко не все. А с gcc производительность удручала.Сейчас даже фиг знает, где их брать.
> Сейчас даже фиг знает, где их брать.Ну почему фиг -- даже я знаю. Но пусть сперва R2000 как надо выпустят ;-)
в смысле - вы неуловимые джо и никому не нужны?
Да как-то не совсем они неуловимые, даже в РФ их полно (вижу сам), в томт числе и последние от оракела. Правда, они там сейчас что-то вроде элитного железа для особых задач.
> сейчас что-то вроде элитного железа для особых задач.которым совершенно по барабану проблемы параллельно выполняющегося на той же системе untrusted кода, которого там никогда не будет и быть не может. О том и речь.
Что-то расхотелось покупать новый процессор от Intel. 🙄 Хотя не заметил чтоб сильно упала производительность. ЦП i3 4330
В 9xxx серии (coffee lake refresh исправили meltdown в кремнии, т.е. у intel теперь должен быть паритет по уязвимостям с amd. Другое дело что нынче процессоры intel стоят слишком дорого.
> В 9xxx серии (coffee lake refresh исправили meltdown в кремнии, т.е. у
> intel теперь должен быть паритет по уязвимостям с amd. Другое дело
> что нынче процессоры intel стоят слишком дорого.Affected processors
-------------------This vulnerability affects a wide range of Intel processors. The
vulnerability is not present on:- Processors from AMD, Centaur and other non Intel vendors
- Older processor models, where the CPU family is < 6
- A range of Intel ATOM processors (Cedarview, Cloverview, Lincroft,
Penwell, Pineview, Silvermont, Airmont, Merrifield)- Intel processors which have the ARCH_CAP_RDCL_NO bit set in the
IA32_ARCH_CAPABILITIES MSR. If the bit is set the CPU is not affected
by the Meltdown vulnerability either. These CPUs should become
available by end of 2018.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
Ну и? Это вообще просто summary.AMD до Разина вообще почти ничему из этого не подвержены. Правда, в 6300 был свои проблемы, но их исправили микрокодом ещё лет 10 назад.
> Ну и? Это вообще просто summary.Это просто ответ на "слишком дорого". Говорят, Atom Z3735F продавали по 5$. И мне интересно, а почем в списке нет Goldmont? Intel XEON PHI то я при копировании случайно пропустил. :)
>Older processor models, where the CPU family is < 6помнится, я как-топ писал, что первые пеньки не подвержены. местные ыксперты меня заминусовали в хлам :))
Я думаю под процессором с битом ARCH_CAP_RDCL_NO наверное и имеют ввиду Coffee lake refresh, они как раз недавно вышли, и вроде в презентациях было сказано что они должны содержать фикс против Meltdown, т.е. на текущий момент разницы в безопасности процессоров между новыми intel и amd нет.
> Я думаю под процессором с битом ARCH_CAP_RDCL_NO наверное и имеют ввиду Coffee
> lake refresh, они как раз недавно вышли, и вроде в презентацияхА я думаю, чего это платы с запаянными процессорами, что стоили чуть дороже "малинок", поднялись в цене? А они, оказывается, по ряду векторов -- Not Affected. В отличие от.
>> The vulnerability is not present on:
>> - Older processor models, where the CPU family is < 6Pentium Pro, family 6 - не подходит, сикурности не завезли.
Pentium MMX, family 5 - походит. Нужно закупаться!А ведь кто-то из посетителей данного ресурса даже еще не родился, а процессор Pentium Pro уже содержал уязвимость.
в старых другие дыры, да и баги опять же
у меня в домашнем роутере такой проц (вроде в середине 00х такие делали)processor : 0
vendor_id : AuthenticAMD
cpu family : 5
model : 10
model name : Geode(TM) Integrated Processor by AMD PCS
stepping : 2
cpu MHz : 498.044
cache size : 128 KB
впрочем, старые атомы тоже подойдут :)
> у меня в домашнем роутере такой процГы, ему мои одноплатники воткнут с присвистом. Кушая 5 ваттов и работая без вентилятора от зарядки для мобли.
> В 9xxx серии (coffee lake refresh исправили meltdown в кремнииУчитывая что теоретически там мелтдауна по спекам не должно было быть вообще нигде - доверять заявлениям интеловского маркетинга будет только завзятый оптимист. Или пиарщик интеля.
> Хотя не заметил чтоб сильно упала производительностьКак правило падение производительности видно не в единичном бенчмарке или тесте, а когда ты за свой рабочий день выполняешь туеву хучу задач, а каждая из них по отдельности "всего лишь на секунду стала медленнее".
Хе, базы данных, виртуализация, до -40%. На десктопе хер ты это увидишь, обычно.
Что страшнее - утечка данных с бд / с хост-нод вм, или с васиного десктопа где 3.5 игрушки? Бывают десктопы с высоким риском утечки, но такие лучше в общую сеть не включать, и софт на них обычно 99% контролируем.
> Что страшнее - утечка данных с бд / с хост-нод вм, или
> с васиного десктопа где 3.5 игрушки?безусловно с васиного десктопа- где у него еще и пароли от всего, что хранит "надежно" его личную и неличную инфу, а то и деньжата, в этих самых тазах банных.
> Бывают десктопы с высоким риском
> утечки, но такие лучше в общую сеть не включать, и софт
> на них обычно 99% контролируем.а на тазу банных у тебя и софт неконтролируемый, и вообще он у тебя в интернет голой задницей смотрит, и хостнода vm не включена даже физически в отдельный изолированный свитч, ага.
Утечка с васиного десктопа затрагивает только васю, а вот с бд-сервера, где хранятся номера счетов, адреса и т.п. - тысячи-миллионы таких вась.
Что же до контролируемости софта - с тем, сколько расплодилось разного рода "девопсов", хранящих данные в различных облачках - утечку они заметят совершенно не сразу, от слова никогда.
Хорошо что сразу всё протестировали и пресекли дешёвые вихляния АМУДЫ с их "а у нас процессоры неподвержены всем уязвимостям"
Спектру подвержены почти все x86 со спекулятивным выполнением, а тут новые спектры нашли.
cpu not found. press any key to software simulations!как-то так. :)
Ржу с этого, теперь проц без фирмвары просто набор транзисторов на силициоме. ПИЧАЛЬКА. И электричество не пригодится раз нет нормальной фирмвары.
Лучше бы Atmel был поглащен Microchip'ом и развитие Z80 с недокоментируемыми командами вместе с Мотороллой и НЕКом со своими DCP, Fujitsu и Altera, толк бы был. А, то догадались x86 на SPARK/ARM аппаратно эмулировать. Бабло есть, а качества "логики" - нет.