Раскрыты (https://people.csail.mit.edu/vlk/spectre11.pdf) сведения о двух новых уязвимостях в механизме спекулятивного выполнения инструкций в процессорах. Уязвимости основываются на тех же принципах, что и метод атаки Spectre 1, поэтому им присвоены кодовые имена Spectre 1.1 (CVE-2018-3693 (https://access.redhat.com/security/cve/cve-2018-3693)) и Spectre 1.2 (CVE пока не назначен). Наличие проблем подтверждено в процессорах Intel (https://01.org/security/advisories/intel-oss-10002) и ARM (https://developer.arm.com/support/arm-security-updates/specu...), подверженность уязвимостям процессоров AMD (https://www.amd.com/en/corporate/security-updates) пока находится под вопросом. В рамках программы (https://www.opennet.ru/opennews/art.shtml?num=48089) по выплате вознаграждений за выявление уязвимостей компания Intel выплатила (https://hackerone.com/vlk?sort_type=latest_disclosable_activ...) исследователям 100 тысяч долларов.
Уязвимость Spectre 1.1 продолжает развитие идей по восстановлению данных, оставшихся в процессорном кэше в результате спекулятивного выполнения инструкций. Новый метод позволяет атакующему получить информацию о содержимом памяти через инициирование выполнения спекулятивных операций, приводящих к переполнению буфера (ключевое отличие от Spectre 1 в том, что для атаки используются спекулятивные операции записи, а не чтения). Несмотря на то, что подобные операции выполняются в ходе спекулятивного выполнения и отбрасываются после определения пересечения границ буфера, их результат оседает в кэше и может быть восстановлен при помощи методов определения содержимого кэша по сторонним каналам, анализирующих изменение времени доступа к прокэшированным и не прокэшированным данным.Проблеме присвоен достаточно низкий уровень опасности (5.9 из 10) так как для организации непривилегированным пользователем атаки для чтения данных из привилегированных областей памяти требуется наличие в привилегированном коде определенной последовательности команд в сочетании с тем, что запись в память производится по адресу, зависящему от внешнего значения, подконтрольного атакующему (например, должны присутствовать конструкции "if
(y
URL: https://01.org/security/advisories/intel-oss-10002
Новость: https://www.opennet.ru/opennews/art.shtml?num=48956
Теперь точно весь перфоманс и ОЗУ будут слиты в браузерах.
Плюс ещё лет 5 ждать нормальных процессоров.
Интересно, как будут вести себя браузеры с исправлением уязвимости на процессорах с исправленной уязвимостью - так же тормозить или будет проверка с фоллбэком?
Внезапно сейчас окажется, что криворукие программисты, кто все это время писал для "быстрых и уязвимых" процессоров, понаписали за эти годы столько всего, что реально будет тормозить на процессорах с заплатками (читай - "слабых и тормозных"), они не в состоянии будут оптимизировать свои "поделия" (уж извините, программами язык не поворачивается назвать).В общем, с текущим кризисом производительности лишь немногие задумаются об оптимизации, и еще более немногие задумаются об образовании и о том, как надо, и как не надо писать код.
Уверен, что качественное ПО будет быстро работать и на процессорах с заплатками. Умные люди найдут способ как оптимизировать их ПО.
> об оптимизации...... которую можно будет произвести только на новых неуязвимых(ТМ) процессорах Intel. Покупайте наших слонов!
скорее это толкает на покупку слонов от амд
Не толкает. Даже в свете последнего года уязвимостей процы амд даже отдаленно не рассматриваются. Проще отключить kpti и всю эту ересь, ибо риск экуспуатации на уровне флуктуаций.
#include <stdflame/85cents>PS: у нас, кстати, весьма удовлетворительно рассматриваются -- взяли EPIC по результатам ощупывания их и Xeon Silver на своих сборочных задачах.
И что же тогда рассматривать? ARM? Так он тоже уязвим. А больше то распространённых процов и нету.
К окулисту сходи.
с чего вы решили, что амудэ не подвержен этим уязвимостям? Не бывает здоровых пациентов, бывают недообследованные...
> Не бывает здоровых пациентов, бывают недообследованные...А ты из каких будешь?
>Плюс ещё лет 5 ждать нормальных процессоров.Нормальных это каких? Itanium уже давно закопали. Если у процессора есть внеочередное выполнение команд и hyper threading то он уязвимый.
>Itanium уже давно закопалиВ мае 2017 вышла последняя ревизия - это уже давно называется?
На localhost:e801-1 ~> lscpu
Архитектура: e2k
Порядок байт: Little Endian
CPU(s): 8
On-line CPU(s) list: 0-7
Thread(s) per core: 1
Ядер на сокет: 8
Сокетов: 1
NUMA node(s): 1
ID прроизводителя: MBE8C-PC v.2
Семейство ЦПУ: 4
Модель: 2
Имя модели: E8C
CPU MHz: 1299.915960
BogoMIPS: 2601.00
NUMA node0 CPU(s): 0-7
он все еще собственное ведро собирает "всего" за пару часиков?
А нормальные тесты производительности по нему когда-нибудь появятся?
Да я видел как Вы с каким-то энтузиастом тестировали 7zip. Меня даже порадовали результаты (думал будет еще хуже), но это только 7zip. Где тесты постгри? Где тесты обработки потокового звука? Да где банальный постфикс с каким-нибудь амависом. Я уж не говорю про все остальное типа видеоконвертирования, 3D и т.д.
Пусть он будет медленным, но любой нормальный покупатель хочет понимать насколько он медленный!!!
А в текущей ситуации это кот в мешке, причем дорого. А такой он нужен только военным и т.п.
Но вот только в США все компьютерные технологии тоже развивались для военных, а потом выводились на обычный рынок. выводились как положено. А у нас...
>>Плюс ещё лет 5 ждать нормальных процессоров.
> Нормальных это каких? Itanium уже давно закопали.О! "" Неслыханный прорыв! Интел выпускает неуязвимый к спектру процессор11 И это Итаник. покупайте**3 ""
> Нормальных это каких?Как каких? Атом!
> Плюс ещё лет 5 ждать нормальных процессоров.да ну, вранье - мне мой атом D2700 обещали за неделю довезти.
(если что - их в той бочке еще сотня штук есть)но вот выпиливать исправление несуществующей уязвимости из ядер, компиляторов и прикладного софта, увы, задача непосильная.
И нет, эти дятлы не умеют ни #ifdef, ни параметров сборки, они умеют только все портить по подсунутым им интеловцами шаблонам.
Не надо ждать 5 лет.. эльбрусы уже поспели)
не надо ждать 5 лет.. эльбрусы уже поспели))
Вброс засчитан.
Spectre непобедим.
Джеймс Бонд успешно победил, и мы сможем!
У Бонда песок уже сыпется. Не сможем
Как я понял для блокирования Spectre при каждом чтении (а теперь и записи) в буфер в цикле нужно вставлять инструкцию LFENCE.В числе примеров уязвимого кода для Spectre 1 (для Spectre 1.1 u[x] поменяется на u[x] = y):
while (++x < limit) {
y = u[x];
thing(y);
}Как же просядет производительность.....
А разве LFNCE надо не между изменением x и чтением по нему ставить, чтоб читало только гарантированно правильные ссылки x?
Ещё от Spectre 4 не пропатчили микрокод (на Убунте как минимум). По Интелу у i3 6100U ревизия должна быть c6, а у меня декабрьская c2. А тут уже новая напасть...Остаётся молиться, изолировать сайты и слушать радио опеннет...
Electron-окодеры в восторге!
Хороший никнейм для данного топика...
> компания Google объявила о включении для 99% пользователей Chrome 67 режима строгой изоляции сайтов1% - сотрудники Интела
Теперь Chrome еще больше памяти будет жрать! :(
Переходите на: https://www.opennet.ru/opennews/art.shtml?num=48845
Никогда!
> Переходите на: https://www.opennet.ru/opennews/art.shtml?num=48845А смысл?
https://groups.google.com/forum/#!topic/firefox-dev/PpZBuRaRkuE
Смысл в том, что FF лучше во всем! Да иногда чуть медленнее, иногда чуть быстрее.
Но с точки зрения безопасности и кастомизируемости он намного лучше!
> Но с точки зрения безопасности и кастомизируемости он намного лучше!Как давний пользователь firefox и предшественников позволю себе поинтересоваться основаниями Вашего оптимизма уже по обоим пунктам (на ESR 60 уже сложно ограничиться только первым).
https://www.mozilla.org/en-US/security/known-vulnerabilities.../ и результаты уже многих pwn2own в помощь. :(
ну например Mozilla правильно закрылась от спектра
на винде у ff свое хранилище сертификатов, а хром юзает системное (которое обновляется апдейтами)
в ff можно элементарно отключить ну например WebRTC, который шарит твой айпишник в локальной сети
в хроме многие штуки нельзя поменять либо меняются через опуа в плане удобства - где в хроме аналог trimURLs?
FF не идеален.. много вопромов к devtools и скорости некторых сайтов, но хром ничем кроме скорости не примечателен.
В принципе Вы правы.
Сам до сих пор сижу на 52 версии. И не приемлю весь ход развития, после увольнения чувака (не помню фамилию) по требованию ЛГПТ.
Но должен признать, что например функционал новых плагинов они допилили например для реализации древовидных вкладок. В принципе из не реализованного никак, из нужного мне, остался только downloadthemall. И этим уже можно попробовать пользоваться.
А вот все мои попытки переехать на другие браузеры заканчивался ничем
в общем со включенным жаваскриптом (флешом, силверлатом, жавой, вебасембли, натрихлором и тд) в инет ни ногой
Доооооо!
Только теплый ламповый elinks
Как только большинство будет сидеть на елинксе, сразу понаходят в нём уязвимостей вида "выход за границы массива при обработке неправильно сформированного хтмл тега, что может привести к %имянапасти%".
А как нахрен отключить все эти защиты от спектр и прочего? Моей бд пофиг на безопасность и нужна только скорость.
Да просто стимулируют покупку новых процов. На рынке застой. Вот и все. Не надо никаких заплаток
Он вопрос задал, а ты зачем-то повторяешь его содержательную часть.
Ну как-то так https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAn...
Боюсь, что это хрень
Новые BIOS пришли, в которых новые cpumicrocode уже с исправлением ряда уязвимостей
Я чего-то не понимаю, но если в BIOS уже исправление в прориетарном cpumicrocode, то будет ли толк от щелканий в ОС?
> Я чего-то не понимаю, но если в BIOS уже исправление в прориетарном cpumicrocode, то будет ли
> толк от щелканий в ОС?микрокод добавляет новые фичи. Которые и использует ОС. Если фичи нет - со спектром сделать нельзя ничего совсем, с мелтдауном можно но будет мээээээдлээээноо
Микрокод добавляет барьер для спекуляции в операцию установки барьера на память.
Без оной операции все будет по старому. Нет волатильности - все быстро и уязвимо. Есть волатильность - медленно и вдумчиво... :)
>Моей бд пофиг на безопасностьОткати ядро на версию без исправлений и спи спокойно. Если твой БД пофиг на безопасность, то уж на красоту циферок в ядрей ей точно пофиг.
2 опции же в grub.conf прописываются для ядра - одна отключает патчи для meltdown другая для spectre
Штамповали веками Intel, AMD и ARM свои бажные процы :(
как будто у нас лучше получился...
> как будто у нас лучше получился...Эльбрус, MIPS подобные, ...
дело не в том у кого лучше получается, а в том что производители скрывают все это
> Эльбрус, MIPS подобные, ...проиграют по производительности даже при изуродованных антиспектромелтдауновыми патчами системах и прикладном софте.
Проиграют и по производительности и по цене - физической изоляции программ на разных физических системах.Ну и зачем оно?
Тот самый случай, когда браузер с одной вкладкой будет жрать ОЗУ больше чем вся операционная система..
Как там у вас, в 2008 году?
в 2008м системы еще были многозадачные, а браузеры полегче, могли и впрямь жрать не столько же, но ненамного больше чем операционная система.это сейчас браузер жрет 90% ресурсов, а системе и оставшихся 10 много, все равно кроме браузера в ней ничего в это время не используется.
В 2008 как раз было иначе. А сейчас так и есть даже если сравнить с кедами, не говоря уж о xfce и матэ.
У нас нормально а у вас спектры и мелтдауны. А ещё браузер требует 128 гигабайт оперативной памяти.
> А ещё браузер требует 128 гигабайт оперативной памяти.Запускаем браузер на кластере, а клиентов подключаем по удаленке к нему. И браузер не тормозит, и можно смотреть, кто где шастает
1гб хватит всем! все остальное можно отдать браузеру.
Может быть проблема в организации современного Веба, предполагающего выполнение на компьютере пользователей кучи недоверенного кода?
Ну, дизайнерам хочется выпендриться анимациями и украшательствами, да плюс есть приложения, где без выполнения кода никуда - те же гуглокарты, в свою время AJAX был просто прорывом
Только почему они стали на столько тормознее при том же функционале?
Хороший вопрос. Видимо потому, что кодирующие макаки окончательно перестали следить за памятью, ибо её OVER 9000. (Ну да, не у всех, но на это им как-то побоку)
Да, программистов нужно обязать работать на устаревшем железе с ограниченным объемом памяти. Или на ARM-одноплатниках каких-нибудь пусть кодят.
С другой стороны (отвечая на свой же комментарий), разграничение на код и данные весьма условно, и граница эта размыта, так что все равно все сводится к тому, что разрешено или не разрешено делать недоверенному коду-данным. Возможно, Джаваскрипту позволено уже слишком много, предоставлен чрезмерный контроль над вычислительными ресурсами пользователя. Но и доминирующая процессорная архитектура оставляет желать много лучшего.
Я так понимаю, теперь каждую неделю будут выходить новые варианты Spectre. И новые патчики. В интересное время живём, однако
Корпорасты сначала наштампуют уязвимых процев, а потом еще с наглой рожей будут втирать вам новые супер быстрые и супер защищенные от всех уязвимостей процессоры. Составляйте коллективные иски, подавайте в суд на корпорастов, требуйте возмещения убытков. Да прибудет с нами сила в этой нелегкой войне.
Только сначала докажите, что от спектрума у вас реальные убытки
еще и еще раз повторюсь: контору MIPS пустили по миру - а это была реальная безопасная альтернатива имеющимся камням.
Жаль только альтернатива эта сливала по производительности всему, что было на рынке в её время. Это её и погубило, а не какой-то ЗАГОВОР.
эта альтернатива была самой производительной на единицу потребляемой мощности.
и почему же cobalt был такое унылое гуано, не подскажете?Уж не потому ли, что мощность оно просто не умело потребить - ибо разгону не подлежало ни вдоль, ни поперек - ни увеличением тактовой, ни параллельностью, которой не умело?
Ну, ещё и Альфу конкуренты аккуратно так распилили...
да пилить там нечего было - полуработающая (и не потому что мс не старалась) NT4 с ошибкой деления на ноль, и совсем ни к чему непригодная фирменная версия юникса за миллион денег без необходимых библиотек, которые и купить-то было потом нельзя.dec, к сожалению, привыкла, что мы слепили хорошую железку, а софт к ней авось кто другой напишет, это не наш бизнес. А оно, внезапно, оказалось никому не надо, софт под нее писать - есть уже один интел, мы уже написали. Тем более что начинать надо было с оптимизирующего компилятора, а он был только у IBM.
да еще и с расширяемостью были проблемы, потому что pci, да не тот. И scsi-диски по непотребным ценам. Ну и кому оно такое надо? Если чо - у знакомых все еще стоит. Но там и производство stone-age.
$ sudo apt get links2
Пусть интел сразу производство 486 возобновляет. Все равно постепенно сольют патчами производительность примерно до того уровня.
Да не не сольют, ту архитектуру можно до 5Ггц разогреть...
Заменил Core i3-530 на Xeon X3440, можно еще 8 лет на 1156 сокете сидеть, только памяти прибавляй.