Исследователи безопасности из группы Zero (http://www.opennet.me/opennews/art.shtml?num=40210), созданной компанией Google для предотвращения атак, совершаемых с использованием ранее неизвестных уязвимостей, продемонстрировали (http://googleprojectzero.blogspot.ru/2015/03/exploiting-dram...) реальность создания рабочих эксплоитов, использующих уязвимость RowHammer (http://www.opennet.me/opennews/art.shtml?num=41340), вызванную особенностями работы современных чипов памяти DRAM.Изначально проблема с памятью DRAM скептически оценивалась многими экспертами, которые считали, что проблема ограничена лишь возможностью совершения отказа в обслуживании, а применение уязвимости для проведения более серьёзных атак считалось нереалистичным. Исследователи сумели опровергнуть данное мнение и задействовали уязвимость для совершения реальных атак, имеющих критический уровень опасности. Подготовлено два эксплоита, которые можно использовать в обычных условиях на штатном потребительском оборудовании. Первый эксплоит позволяет организовать выполнение кода с правами ядра системы. Второй вариант атаки даёт возможность обойти sandbox-изоляцию Native Client в браузере Chrome (CVE-2015-0565).
В качестве методов блокирования проявления проблемы, кроме внесения изменений на аппаратном уровне, упоминается ряд обходных путей защиты, которые можно применить на уровне ОС или выпустив обновления BIOS и прошивок. Например, повышение частоты обновления DRAM существенно затрудняет проведение атаки, а использование счётчиков производительности CPU позволяет выявлять факты осуществления атак. В Native Client блокировать уязвимость удалось добавив в систему верификации кода запрет на использование инструкции
CLFLUSH.
В отчёте также указывается на важность публичного обнародования сведений о выявляемых проблемах. Судя по всему производители знали об уязвимости уже давно, о чём свидетельствуют представленные в стандарте LPDDR4 два метода защиты от уязвимости, но не спешили реализовать исправления и предупредить пользователей, так как считали уязвимость неопасной и влияющей только на стабильность.
Напомним, что в прошлом году группа исследователей обратила внимание на достаточно простой способ проявления эффекта искажения содержимого отдельных битов памяти DRAM - повреждение отдельных битов DRAM-памяти можно инициировать путём цикличного чтения данных из соседних ячеек памяти (простой цикл с чтением содержимого памяти и очисткой кэша). Проблема обусловлена особенностью работы памяти DRAM, которая формируется как двухмерный массив ячеек, каждая из которых состоит из конденсатора и транзистора.
Состояние сохранённого в ячейке значения определяется тем, заряжен или нет конденсатор. Для поддержания заряда применяется цикл регенерации. При выполнении непрерывного чтения одной и той же области памяти из-за постоянного открытия и закрытия линии WL (Word Line), которая управляет транзисторами доступа, возникают флуктуации напряжения, которые могут привести к аномалии, вызывающей небольшую потерю заряда соседних ячеек. Если интенсивность чтения достаточно большая, то ячейка может потерять достаточно большой объём заряда и очередной цикл регенерации не успеет восстановить его первоначальное состояние, что приведёт к изменению значения сохранённых в ячейке данных.URL: http://googleprojectzero.blogspot.ru/2015/03/exploiting-dram...
Новость: http://www.opennet.me/opennews/art.shtml?num=41817
Если кто-то использует не ECC память в серверах или не мониторит ECC'шные ошибки, то он ССЗБ.
А на домашнем компе тоже ECC прикажите юзать?
Приказываю вам юзать домашнем компе тоже ECC !И учить русского языка.
Будешь смеяться, но в моем первом была ECC-память. До сих пор не знаю, на кой туда ее запихнул сборщик (я в те годы был еще полным ламером и сам компы не собирал). Но она там действительно была и работала. Конфиг был, по тем временам, неплохой: четвертый пень, 512 метров самсунговой ECC-памяти (2*256) и так далее...Память эту я, впоследствии, удачно продал какому-то чуваку для апгрейда его сервера.
> Будешь смеяться, но в моем первом была ECC-память. До сих пор не
> знаю, на кой туда ее запихнул сборщик (я в те годы
> был еще полным ламером и сам компы не собирал). Но она
> там действительно была и работала. Конфиг был, по тем временам, неплохой:
> четвертый пень, 512 метров самсунговой ECC-памяти (2*256) и так далее...
> Память эту я, впоследствии, удачно продал какому-то чуваку для апгрейда его сервера.Когда говорят что у них бил первый комп P4 я чувствую себя стариком.
Не льсти себе. Если гордишься возрастом, то еще недостаточно стар =)
Мой то первый был zx spectrum самосборный. Я стар. Просто суперстар.
> Мой то первый был zx spectrum самосборный. Я стар. Просто суперстар.А БК-0010 не застал? :) Если нет, то ты даже не стар :)
А я вот начинал с Электроники МК-61 :)
Обратная польская нотация :)
> А я вот начинал с Электроники МК-61 :)
> Обратная польская нотация :)Ну МК-61 всё-таки лучше не считать, потому что это очень узкоспециализированное железо. Калькулятор же (FPU), а не CPU общего назначения. И памяти всего ничего. ЕГГОГ - это конечно навсегда :)
Не, я менее стар :) У мну тоже был, конечно, но в начальной школе, а классе в седьмом мы уже на ZX'овый асм подсели...
> Ну МК-61 всё-таки лучше не считать, потому что это очень узкоспециализированное железо- Тем не менее ...к ней было сделанно уйма программ и не только научно рассчётных программ, но уйма игр и даже динамических с Р-Г-Д пермеключателем в качестве джойстика,
несмотря на её 101 байт для программы с байт кодом и 15+5 доступных регистров с плавающей точкой.
Сравнительно с иностранынми аналогами - низкая цена за такой карманный ПК и тем более просто ПК...
И вообще: более 50 лет пользования... В сети - и поныне можно увидеть объявления о продажи рабочих экземпляров, не говоря уже (про правда неудачную попытку создания его весьма неточного клона (чисто по API)), а также сайты с программами и эмляции в том числе с сверхточной(со слов) на базе реконструированных микропрограмм.И ниодин этот ваш Core x100500 ЦПУ- не обладает такой характеристикой
...как заложеную при проектированнии - работу в качестве автономного заменителя спутниковых Бортовых Компьютеров,
на случай выхода тех из строя.
И читал ещё что, многие шарящие военные тоже долго предпочитали(
а может и поныне предпочитают) именно эту серию, даже немотря на нужность подвоза "вагонов" батареек(впрочем розетку и те же перезаряжаемые батареи - никто не отменял)
- всяким там: тонюсеньким и графическим Casio и т.п.
(предполагаю как ЭМ защищённые)
"Число" "В/О" "С/П" помню-помню, с него-то я и начинал в детстве играть и программировать. :-)
> там действительно была и работала.В современных AMD, как минимум с socket AM2 и 3, серий FX - работает unbuffered ECC память. Дело в том что контроллер памяти у амдшных процов поддерживает ECC, а большинство мамок разводит все линии к памяти и BIOS в курсе фичи. Даже если поддержка и не заявлена официально.
ECC стоит копейки, так что да.
> ECC стоит копейки, так что да.а материнская плата это умеющая?
>> ECC стоит копейки, так что да.
> а материнская плата это умеющая?http://market.yandex.ru/product/8529723/
Supermicro X9SAE-V - 15 840 руб.
самое дешевое...
совсем копейки че...
> совсем копейки че...Gigabyte с сокетом AM3 можно найти раза в три дешевле. И да, там работает ECC ;)
Ну покажи нам хоть одно предложение c такой ценой. Я бы посмотрел на полноценную материнку за $10-$12.
Материнку за $10-$12?
http://market.yandex.ru/catalog/91020/list?gfilter=214256045...
всякие есть
К стати про материнскую плату,умеющею ЕСС,была статья в которой говорилось,что спец процессор управления питанием или нечто подобное тот ещё зонд с выходом в сеть.
И вроде как говорилось что в серверный БИОС встроена возможность зайти кому надо по сети и выкачать дамп ОЗУ.
> К стати про материнскую плату,умеющею ЕСС,была статья в которой говорилось, что
> спец процессор управления питанием или нечто подобное тот ещё зонд с выходом в сеть.Это была статья на ксакепе про IPMI BMC, вообще-то написанная достаточно грамотно и изложенное похоже на правду (как минимум вполне возможно).
BMC-шки действительно обычно встречаются ровно там же, где и ECC-память -- на серверных материнках, но ход мысли получился оригинальный ;-)
> и изложенное похоже на правду (как минимум вполне возможно).У Рутковской можно укачать прототип руткита для "ring -3", который вгружал себя в память BMC и оттуда периодически делал запись в системную память. PoC безобидный, но убедительный. Правда требует вполне конкретного железа для работы, но это ж дело наживное. Так что BMC который возжелает нагадить - вполне реален. А у супермикро, где оказался стандартный инженерный пароль - так и вовсе кто угодно мог порулить системой как угодно.
> BMC-шки действительно обычно встречаются ровно там же, где и ECC-память
Юзеры амдшных процов просто не просекли что АМД им забесплатно подарок подогнали, сделав в многих десктопных процах контроллер памяти с поддержкой ECC.
Похоже на правду ? Для вас ?
Это статья из журнала Xakep
https://xakep.ru/2011/12/26/58104/
Которая является обычной "клюквой", написанной подростком с богатой фантазией, и на аналогичную аудиторию и ориентированная. Ну и на тех, кто задержался в своем развитии в этом возрасте.
Причем я не спорю, что описанная ситуация теоретически возможна, но конкретно описанный случай вызывает очень серьезные сомнения. И далеко идущие последствия, особенно для корпорации Intel и ее заводов в Китае. Прежде всего потому, что он очень легко проверяется, если автор бы указал минимальные технические детали. Модель и серийный номер материнской платы, к примеру. Но он забыл. Зато не забыл схемы, нарисованные карандашом на салфетке, и сделанные с экрана скриншоты "тестов". Исходники тестов, правда, тоже забыл.
Особенно прошибает слезу место, где описываются попытки автора донести угрозу до специалистов из спецслужб, где сидят голимые идиоты. Левша v2015.0, не иначе.
http://www.youtube.com/watch?v=neTeMxpUtUM&feature=player_de...
Так что я скорее поверю в троян в прошивке винта от Касперского.
> Похоже на правду ? Для вас ?Да.
> Это статья из журнала Xakep
Я это указал (и это как раз предупреждение).
> Которая является обычной "клюквой", написанной подростком с богатой фантазиейНет.
>> Которая является обычной "клюквой", написанной подростком с богатой фантазией
>Нет.Чудо - аргумент. Для детского сада. Мог бы вообще не отвечать, раз сказать нечего.
Похоже: какой аргумент - такой и контраргумент...
>"является обычной "клюквой", написанной подростком с богатой фантазией"...
Да забавно, инострнные ЦПУ с AMT и аналогом у других - ныне в РФ незаконны:
"Применение иностранных криптографических средств с длиной ключа более 40 бит запрещено на территории России законодательно, а тут — пожалуйста! — в каждом сервере Intel криптомодуль с неизвестными ключами длиной 256 бит. Более того, эти ключи использовались для шифрования программ, зашитых в микросхемы материнской платы на этапе производства.Выходит, что блоки ВМС в России на серверах Intel, которые имеют в своем составе чипсет 5000х, должны быть отключены. Однако эти блоки, напротив, всегда находятся в рабочем состоянии, даже если сама вычислительная установка отключена (для функционирования ВМС достаточно дежурного напряжения, то есть вставленного в розетку кабеля питания сервера). "
> а материнская плата это умеющая?Почти любая десктопная AM2/AM3 плата + AMD проц серии FX потянут ECC unbuffered память.
>> а материнская плата это умеющая?
> Почти любая десктопная AM2/AM3 плата + AMD проц серии FX потянут ECC
> unbuffered память.И планки лобзиком пилить под соответствующий разъем?
> И планки лобзиком пилить под соответствующий разъем?Разъёмы и расположение ключа у ECC/non-ECC unbuffered вполне себе одинаковые.
Более того - у меня именно ECC DRAM в мамке с AM3+ сокетом. Даже работает. Линь вполне себе цепляет это модулем EDAC.
> а материнская плата это умеющая?Это не совсем правильный вопрос. Дело в том, что по статистике большинство пользовательских компов - ноуты. А сколько материнских плат ноутбуков поддерживает ECC?
> Это не совсем правильный вопрос. Дело в том, что по статистике большинство
> пользовательских компов - ноуты. А сколько материнских плат ноутбуков поддерживает ECC?AMD'шные скорее всего поддерживают - как правильно сказано, там контроллер в проце поддерживает, и пины разведены как правило все.
AM3(+) - любой асус, даже самый дешманский, умеет ЕСС. Как и АМ2/939/754. У других производителей - обычно ЕСС только на топах.Интел - там все более запущено.
Ну это возможно
> А на домашнем компе тоже ECC прикажите юзать?Ну вот у меня на домашнем десктопе память с ECC. Нет, я не покупал серверные мамки. Спасибо АМД за ECC контроллер памяти в десктопном проце :)
> Если кто-то использует не ECC память в серверах или не мониторит ECC'шные
> ошибки, то он ССЗБ.И что делать при возникновении ошибки? Ребутить комп автоматом?
> И что делать при возникновении ошибки?ECC в состоянии исправить единичный переворот бита. И детектировать множественные перевороты битов в ряде случаев. Что по этому поводу делать - есть разные варианты.
Проверил тулзой свой домашний "десктопный" сервер. GA-890FXA-UD5, Samsung DDR3 (не-ECC), планки по 8 гиг. 100 итераций, проблемы не выявлено. Так что дело не только в ECC. Возможно, ещё особенности контроллеров памяти и самих чипов влияют.
Ну чо, все померялись ECC пиписками?... Ну тогда гуглите прайсы.
Домашний компик:TYAN S8225
Два AMD Opteron 4386
8 x 16 Гб. ECC Reg. DDR3 CL9
3 SSD по 520 Гб.
Geforce Titan
Geforce 470
Geforce 250Приезжайте в гости, погреться у жифорсов. :)
---
Чот оно целый час дДоСило и не продосило.
./a.out
#0 ........................................ OK
#1 ........................................ OK
#2 ........................................ OK
#3 ........................................ OK
#4 ........................................ OK
#5 ........................................ OK
#6 ........................................ OK
#7 ........................................ OK
#8 ........................................ OK
#9 ........................................ OK
#10 ........................................ OK
#11 ........................................ OK
#12 ........................................ OK
#13 ........................................ OK
#14 ........................................ OK
#15 ........................................ OK
#16 ........................................ OK
#17 ........................................ OK
#18 ........................................ OK
#19 ........................................ OK
#20 ........................................ OK
#21 ........................................ OK
#22 ........................................ OK
#23 ........................................ OK
#24 ........................................ OK
#25 ........................................ OK
#26 ........................................ OK
#27 ........................................ OK
#28 ........................................ OK
#29 ........................................ OK
#30 ........................................ OK
#31 ........................................ OK
#32 ........................................ OK
#33 .DRAM seems works fine...
Простите, а никто не в курсе что ECC в большинстве случаев основано на коде Хэмминга и потому принципиально не способно детектировать чётное количество ошибок? Т.е. если у вас 2 битика перекинутся в другие состояния, то ECC это не определит.
Ошибаетесь. уважаемый, для того, чтобы ECC не отреагировало на проблему нужно не менее 4-х ошибок, причем не абы каких, а расположенных в строго определенном порядке. Дело в том, что для каждых 8 байт чексуммы строятся и по горизонтали (для каждого байта), и по вертикали (для N-го бита каждого из байтов). Именно это позволяет исправлять единичные ошибки.
> Ошибаетесь. уважаемый, для того, чтобы ECC не отреагировало на проблему нужно не
> менее 4-х ошибок, причем не абы каких, а расположенных в строго
> определенном порядке. Дело в том, что для каждых 8 байт чексуммы
> строятся и по горизонтали (для каждого байта), и по вертикали (для
> N-го бита каждого из байтов). Именно это позволяет исправлять единичные ошибки.Пруфлинк пожалуйста, на то что *все* ECC модули памяти используют описанный вами алгоритм. Простейший случай с кодом Хэмминга чётные ошибки не отлавливает.
>> Ошибаетесь. уважаемый, для того, чтобы ECC не отреагировало на проблему нужно не
>> менее 4-х ошибок, причем не абы каких, а расположенных в строго
>> определенном порядке. Дело в том, что для каждых 8 байт чексуммы
>> строятся и по горизонтали (для каждого байта), и по вертикали (для
>> N-го бита каждого из байтов). Именно это позволяет исправлять единичные ошибки.
> Пруфлинк пожалуйста, на то что *все* ECC модули памяти используют описанный вами
> алгоритм. Простейший случай с кодом Хэмминга чётные ошибки не отлавливает.Сейчас код Хэминга только в школах проходят.
Freescale: http://cache.freescale.com/files/32bit/doc/app_note/AN3532.pdf
Altera: https://www.altera.com/en_US/pdfs/literature/an/an415.pdf
Xilinx: http://www.xilinx.com/support/documentation/ip_documentation...А ваще, грубо говоря, эти алгоритмы - секрет производителей.
> Сейчас код Хэминга только в школах проходят.Завидую вашим школам. В наших школах 22% 15-летних россиян обладают навыками чтения ниже минимально допустимого уровня. К сожалению.
Но даже если это и так - от того что в школах проходят законы физики, они не перестают использоваться на практике. И что-то мне подсказывает что в разработке же памяти важна не только (и не столько) навороченность алгоритма, а ещё и возможная скорость его работы и простота/дешевизна реализации. Которые ограничиваются всё теми же законами физики.> Freescale: http://cache.freescale.com/files/32bit/doc/app_note/AN3532.pdf
> Altera: https://www.altera.com/en_US/pdfs/literature/an/an415.pdf
> Xilinx: http://www.xilinx.com/support/documentation/ip_documentation...А ведь изначально тут был текст который мне свалился в почту и в котором было написано:
> two-bit errors cannot be corrected because multiple valid SECDED codewords can
> result in the same error vector with different two-bit errors.;-)
К сожалению мне некогда читать такие кирпичи. Можете указать конкретную страницу где указано то что вы мне пытаетесь донести?> А ваще, грубо говоря, эти алгоритмы - секрет производителей.
Т.е. на самом деле доказывать нечем получается.
PS Я всё это не спора ради, а мне действительно интересно узнать как оно на самом деле. Т.к. в *общедоступной* информации по ECC памяти по прежнему пишут про код Хэмминга.
Теоретик? ECC _обязан_ по стандарту исправлять единичные ошибки и выявлять двойные. А ваш детсадовский алгоритм не позволит решить ни одну из этих задач.
> Теоретик? ECC _обязан_ по стандарту исправлять единичные ошибки и выявлять двойные. А
> ваш детсадовский алгоритм не позволит решить ни одну из этих задач.Оо, больше ненависти дорогой анонимус! Я всего-лишь пытаюсь дойти до правды и оперировать при этом проверенными и авторитетными данными, а не мнениями "авторитетных анонимусов". Так что свои лучи любви и троллинга приберегите для кого-нибудь другого.
Болтовню без пруфлинков по техническим вопросам я склонен игнорировать.PS Код Хэмминга - "мой детсадовский алгоритм", эх, о времена, о нравы...
> браузере ChromeХромогопробелемы.
Нет!
"Первый эксплоит позволяет организовать выполнение кода с правами ядра системы" - ничего не говорит?
Читайте о двух проблемах:
"Первый эксплоит позволяет организовать выполнение кода с правами ядра системы.
Второй вариант атаки даёт возможность обойти sandbox-изоляцию Native Client в браузере Chrome (CVE-2015-0565)".
>> браузере Chrome
> Хромогопробелемы.Хрен тебе. Это проблемы хромого железа.
вот блин жесть...
"Стало страшно жить до жути" (с)
Косяк архитектуры. Область кода и область данных не разграничиваются.
Все на Гарвард?-)
Ну-ну. ;)
Как буто это что-то плохое!
> Как буто это что-то плохое!Это плохое, да. Очень геморно программится и сношает мозг искусственными ограничениями.
До С++11 ему далеко :)
Гугл очень вовремя прекратил поддержку "старых" ядер линкса в хромиуме...
> Гугл очень вовремя прекратил поддержку "старых" ядер линкса в хромиуме...Пора прекращать поддержку старых DRAM-ов!
Так ведь новых-то еще нет, фактически... :)
Кто-нибудь, отучите наконец уже митрофанушку выделять восклицательный знак курсивом.
> Кто-нибудь, отучите наконец уже митрофанушку выделять восклицательный знак курсивом.Работает же! </>
А нельзя пользовательским программам запретить чистить кэш и не парить мозг?
Как ты инструкцию CLFLUSH запретишь?
F0 0F C7 C8 запретили же как-то. А по-уму - интел должен был CLFLUSH сделать ограниченной, это ж если каждый процесс начнет кэш чистить - чистый ddos получится.
И как это сделать? Как повлияет на скорость JIT (.net, java и прочие)?
Если процесс начнет интенсивно кэш чистить — задосит он лишь себя любимого (ну, без учета открывшегося эксплойта). А то давай еще бесконечные циклы запретим? Или вообще интенсивные вычисления? Это ж если каждый процесс начнет много сложных операций выполнять — чистый ddos получится.И если уж на то пошло, то это создатели памяти должны были позаботиться, чтобы интенсивное чтение из нее не разрушало данные, нет? Вот только оказалось, что а) для этого надо снизить скорость доступа к памяти, б) такой сценарий редок, спасибо процессорному кэшу. Ну, они и соптимизировали: вместо правильно работающей, но дорогой вещи сделали немного неправильную, но гораздо более дешевую.
Если у нескольких ядер общий кэш, то очистка одним процессом "своего" кэша - будет влиять негативно на другие ядра, с их собственными процессами (забиваться будет шина памяти постоянным потоком данных этого чистильщика).
...то есть запретить for (i = 0; i < 16; i++) { memmove(dst_bufs[i], src_bufs[i], 1024 * 1024); }, потому что оно весь кэш же угробит, да?Если процесс активно модифицирует память, то либо понижай его приоритет, если этот процесс для тебя маловажен, чтобы более важные процессы получали больше ресурсов; либо нет, потому что он works as intended: проворачивает большой объем нужной тебе работы, используя ресурсы процессора эффективно, т.е. для этой самой работы, отбирая эти ресурсы у остальных, менее важных, процессов.
Тут вся проблема — дырявая абстракция, что память под высокой нагрузкой начинает вдруг ломаться неожиданным образом, и если подобрать хитрую загрузку, то она сломается выгодным кому-то (и невыгодным тебе) способом.
>[оверквотинг удален]
> memmove(dst_bufs[i], src_bufs[i], 1024 * 1024); }, потому что оно весь кэш
> же угробит, да?
> Если процесс активно модифицирует память, то либо понижай его приоритет, если этот
> процесс для тебя маловажен, чтобы более важные процессы получали больше ресурсов;
> либо нет, потому что он works as intended: проворачивает большой объем
> нужной тебе работы, используя ресурсы процессора эффективно, т.е. для этой самой
> работы, отбирая эти ресурсы у остальных, менее важных, процессов.
> Тут вся проблема — дырявая абстракция, что память под высокой нагрузкой начинает
> вдруг ломаться неожиданным образом, и если подобрать хитрую загрузку, то она
> сломается выгодным кому-то (и невыгодным тебе) способом.Спыцыалисты... йоптя...
> Как ты инструкцию CLFLUSH запретишь?Как два байта об асфальт
1. указываешь ядру при загрузке "noclflush"
Тока в обморок не падайте, есть ещо штук 5-6 инструкций для сброса.
В случае ядра линя будет использоваться wbinvd2.
diff --git a/arch/x86/include/asm/special_insns.h b/arch/x86/include/asm/special_insns.h
index 6a4b00f..6c40a2e 100644
--- a/arch/x86/include/asm/special_insns.h
+++ b/arch/x86/include/asm/special_insns.h
@@ -188,7 +188,7 @@ static inline void clts(void)
static inline void clflush(volatile void *__p)
{
- asm volatile("clflush %0" : "+m" (*(volatile char __force *)__p));
+ asm volatile("wbinvd");
}
static inline void clflushopt(volatile void *__p)ну и далее по тексту ...
Эмм... ну не будет ядро использовать CLFLUSH. И что? Вот код, собственно вызывающий уязвимость:code1a:
mov (X), %eax // Read from address X
mov (Y), %ebx // Read from address Y
clflush (X) // Flush cache for address X
clflush (Y) // Flush cache for address Y
jmp code1a
Ты процессору как запретишь исполнять clflush? Или предлагаешь во всех программах его выпатчить? Синхронизация от этого ни у кого не убьется? Специалист...
> Эмм... ну не будет ядро использовать CLFLUSH. И что? Вот код, собственно
> вызывающий уязвимость:
> code1a:
> mov (X), %eax // Read from address X
> mov (Y), %ebx // Read from address Y
> clflush (X) // Flush cache for address X
> clflush (Y) // Flush cache for address Y
> jmp code1a
> Ты процессору как запретишь исполнять clflush? Или предлагаешь во всех программах его
> выпатчить? Синхронизация от этого ни у кого не убьется? Специалист...Ты ваще в курсе как ОС работают? Думаешь код на асме накодишь и оно сразу в процессор летит?
> Синхронизация от этого ни у кого не убьется?
wbinvd та же хрень, только старая и сбрасывает все кэши.
С этой инструкцией только стабильнее будет, чуть тормознутее,
но лучше, особо на многотредовых приложениях с общими переменными.
Да, я в курсе. И если в бинарнике лежат байты 0F AE в секции кода, и исполнение дойдет до них — то процессор их выполнит (это CLFLUSH), и ничего ОС с этим не сделает. А они там лежать будут, потому что ОС не трассирует (как правило) выполнение пользовательского кода, а исправить произвольный код перед запуском на нужный на практике нереально.
Вот бабла срубит автор второго эксплоита от Google...
А он там и работает. как раз над nacl sandbox'ом
Какое же халтурное дерьмищще! нам подсовывают.