The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Продемонстрировано использование уязвимости в DRAM-памяти для повышения привилегий в системе

10.03.2015 17:26

Исследователи безопасности из группы Zero, созданной компанией Google для предотвращения атак, совершаемых с использованием ранее неизвестных уязвимостей, продемонстрировали реальность создания рабочих эксплоитов, использующих уязвимость RowHammer, вызванную особенностями работы современных чипов памяти DRAM.

Изначально проблема с памятью DRAM скептически оценивалась многими экспертами, которые считали, что проблема ограничена лишь возможностью совершения отказа в обслуживании, а применение уязвимости для проведения более серьёзных атак считалось нереалистичным. Исследователи сумели опровергнуть данное мнение и задействовали уязвимость для совершения реальных атак, имеющих критический уровень опасности. Подготовлено два эксплоита, которые можно использовать в обычных условиях на штатном потребительском оборудовании. Первый эксплоит позволяет организовать выполнение кода с правами ядра системы. Второй вариант атаки даёт возможность обойти sandbox-изоляцию Native Client в браузере Chrome (CVE-2015-0565).

В качестве методов блокирования проявления проблемы, кроме внесения изменений на аппаратном уровне, упоминается ряд обходных путей защиты, которые можно применить на уровне ОС или выпустив обновления BIOS и прошивок. Например, повышение частоты обновления DRAM существенно затрудняет проведение атаки, а использование счётчиков производительности CPU позволяет выявлять факты осуществления атак. В Native Client удалось блокировать уязвимость, добавив в систему верификации кода запрет на использование инструкции CLFLUSH.

В отчёте также указывается на важность доведения до всеобщего сведения информации о выявляемых проблемах. Судя по всему производители знали об уязвимости уже давно, о чём свидетельствуют представленные в стандарте LPDDR4 два метода защиты от уязвимости, но не спешили реализовать исправления и не предупредили пользователей, так как считали уязвимость неопасной и влияющей только на стабильность.

Напомним, что в прошлом году группа исследователей обратила внимание на достаточно простой способ проявления эффекта искажения содержимого отдельных битов памяти DRAM - повреждение отдельных битов DRAM-памяти можно инициировать путём цикличного чтения данных из соседних ячеек памяти (простой цикл с чтением содержимого памяти и очисткой кэша). Проблема обусловлена особенностью работы памяти DRAM, которая формируется как двухмерный массив ячеек, каждая из которых состоит из конденсатора и транзистора.

Состояние сохранённого в ячейке значения определяется тем, заряжен или нет конденсатор. Для поддержания заряда применяется цикл регенерации. При выполнении непрерывного чтения одной и той же области памяти из-за постоянного открытия и закрытия линии WL (Word Line), которая управляет транзисторами доступа, возникают флуктуации напряжения, которые могут привести к аномалии, вызывающей небольшую потерю заряда соседних ячеек. Если интенсивность чтения достаточно большая, то ячейка может потерять достаточно большой объём заряда и очередной цикл регенерации не успеет восстановить его первоначальное состояние, что приведёт к изменению значения сохранённых в ячейке данных.

  1. Главная ссылка к новости (http://googleprojectzero.blogs...)
  2. OpenNews: Содержимое ячеек DRAM может быть повреждено в результате цикличного чтения
  3. OpenNews: Google представил проект Zero, нацеленный на повышение защищённости Сети
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/41817-dram
Ключевые слова: dram, security
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (80) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 18:18, 10/03/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –7 +/
    Если кто-то использует не ECC память в серверах или не мониторит ECC'шные ошибки, то он ССЗБ.
     
     
  • 2.4, Аноним (-), 18:37, 10/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    А на домашнем компе тоже ECC прикажите юзать?
     
     
  • 3.5, Аноним (-), 18:49, 10/03/2015 [^] [^^] [^^^] [ответить]  
  • +21 +/
    Приказываю вам юзать домашнем компе тоже ECC !

    И учить русского языка.

     
  • 3.8, Anonplus (?), 19:20, 10/03/2015 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Будешь смеяться, но в моем первом была ECC-память. До сих пор не знаю, на кой туда ее запихнул сборщик (я в те годы был еще полным ламером и сам компы не собирал). Но она там действительно была и работала. Конфиг был, по тем временам, неплохой: четвертый пень, 512 метров самсунговой ECC-памяти (2*256) и так далее...

    Память эту я, впоследствии, удачно продал какому-то чуваку для апгрейда его сервера.

     
     
  • 4.11, Аноним (-), 19:41, 10/03/2015 [^] [^^] [^^^] [ответить]  
  • +44 +/
    > Будешь смеяться, но в моем первом была ECC-память. До сих пор не
    > знаю, на кой туда ее запихнул сборщик (я в те годы
    > был еще полным ламером и сам компы не собирал). Но она
    > там действительно была и работала. Конфиг был, по тем временам, неплохой:
    > четвертый пень, 512 метров самсунговой ECC-памяти (2*256) и так далее...
    > Память эту я, впоследствии, удачно продал какому-то чуваку для апгрейда его сервера.

    Когда говорят что у них бил первый комп P4 я чувствую себя стариком.

     
     
  • 5.22, Аноним (-), 22:06, 10/03/2015 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Не льсти себе. Если гордишься возрастом, то еще недостаточно стар =)
     
  • 5.49, Ононим (?), 09:43, 12/03/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Мой то первый был zx spectrum самосборный. Я стар. Просто суперстар.
     
     
  • 6.51, AlexAT (ok), 09:48, 12/03/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Мой то первый был zx spectrum самосборный. Я стар. Просто суперстар.

    А БК-0010 не застал? :) Если нет, то ты даже не стар :)

     
     
  • 7.57, Стареем (?), 11:35, 12/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
      А я вот начинал с Электроники МК-61 :)
    Обратная польская нотация :)
     
     
  • 8.67, AlexAT (ok), 08:36, 13/03/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну МК-61 всё-таки лучше не считать, потому что это очень узкоспециализированное ... текст свёрнут, показать
     
     
  • 9.79, Аноним (-), 19:56, 05/06/2017 [^] [^^] [^^^] [ответить]  
  • +/
    - Тем не менее к ней было сделанно уйма программ и не только научно рассчётны... большой текст свёрнут, показать
     
     
  • 10.80, Аноним (-), 20:01, 05/06/2017 [^] [^^] [^^^] [ответить]  
  • +/
    предполагаю как ЭМ защищённые ... текст свёрнут, показать
     
  • 10.81, Ilya Indigo (ok), 20:03, 05/06/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Число В О С П помню-помню, с него-то я и начинал в детстве играть и програ... текст свёрнут, показать
     
  • 4.27, Аноним (-), 00:30, 11/03/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > там действительно была и работала.

    В современных AMD, как минимум с socket AM2 и 3, серий FX - работает unbuffered ECC память. Дело в том что контроллер памяти у амдшных процов поддерживает ECC, а большинство мамок разводит все линии к памяти и BIOS в курсе фичи. Даже если поддержка и не заявлена официально.

     
  • 3.15, Анон666 (?), 20:49, 10/03/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    ECC стоит копейки, так что да.
     
     
  • 4.18, Аноним (-), 20:57, 10/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > ECC стоит копейки, так что да.

    а материнская плата это умеющая?

     
     
  • 5.19, Аноним (-), 21:00, 10/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >> ECC стоит копейки, так что да.
    > а материнская плата это умеющая?

    http://market.yandex.ru/product/8529723/
    Supermicro X9SAE-V - 15 840 руб.
    самое дешевое...
    совсем копейки че...

     
     
  • 6.33, Аноним (-), 00:40, 11/03/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > совсем копейки че...

    Gigabyte с сокетом AM3 можно найти раза в три дешевле. И да, там работает ECC ;)

     
     
  • 7.41, angra (ok), 14:11, 11/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Ну покажи нам хоть одно предложение c такой ценой. Я бы посмотрел на полноценную материнку за $10-$12.
     
     
  • 8.45, Serge (??), 18:17, 11/03/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Материнку за 10- 12 ... текст свёрнут, показать
     
  • 5.20, Аноним (-), 21:24, 10/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    http://market.yandex.ru/catalog/91020/list?gfilter=2142560456:-1348466349&how
    всякие есть
     
  • 5.21, torvn77 (ok), 21:47, 10/03/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    К стати про материнскую плату,умеющею ЕСС,была статья в которой говорилось,что спец процессор управления питанием или нечто подобное тот ещё зонд с выходом в сеть.
    И вроде как говорилось что в серверный БИОС встроена возможность зайти кому надо по сети и выкачать дамп ОЗУ.
     
     
  • 6.26, Michael Shigorin (ok), 00:22, 11/03/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > К стати про материнскую плату,умеющею ЕСС,была статья в которой говорилось, что
    > спец процессор управления питанием или нечто подобное тот ещё зонд с выходом в сеть.

    Это была статья на ксакепе про IPMI BMC, вообще-то написанная достаточно грамотно и изложенное похоже на правду (как минимум вполне возможно).

    BMC-шки действительно обычно встречаются ровно там же, где и ECC-память -- на серверных материнках, но ход мысли получился оригинальный ;-)

     
     
  • 7.32, Аноним (-), 00:38, 11/03/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > и изложенное похоже на правду (как минимум вполне возможно).

    У Рутковской можно укачать прототип руткита для "ring -3", который вгружал себя в память BMC и оттуда периодически делал запись в системную память. PoC безобидный, но убедительный. Правда требует вполне конкретного железа для работы, но это ж дело наживное. Так что BMC который возжелает нагадить - вполне реален. А у супермикро, где оказался стандартный инженерный пароль - так и вовсе кто угодно мог порулить системой как угодно.

    > BMC-шки действительно обычно встречаются ровно там же, где и ECC-память

    Юзеры амдшных процов просто не просекли что АМД им забесплатно подарок подогнали, сделав в многих десктопных процах контроллер памяти с поддержкой ECC.

     
  • 7.71, Легион (?), 16:16, 13/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Похоже на правду Для вас Это статья из журнала Xakep https xakep ru 2011 ... большой текст свёрнут, показать
     
     
  • 8.73, Michael Shigorin (ok), 16:29, 13/03/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Да Я это указал и это как раз предупреждение Нет ... текст свёрнут, показать
     
     
  • 9.74, Легион (?), 16:32, 13/03/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Чудо - аргумент Для детского сада Мог бы вообще не отвечать, раз сказать нечег... текст свёрнут, показать
     
     
  • 10.82, Аноним (-), 20:15, 05/06/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Похоже какой аргумент - такой и контраргумент ... текст свёрнут, показать
     
     
  • 11.83, Аноним (-), 20:18, 05/06/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Да забавно, инострнные ЦПУ с AMT и аналогом у других - ныне в РФ незаконны При... текст свёрнут, показать
     
  • 5.28, Аноним (-), 00:31, 11/03/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > а материнская плата это умеющая?

    Почти любая десктопная AM2/AM3 плата + AMD проц серии FX потянут ECC unbuffered память.

     
     
  • 6.50, Ононим (?), 09:46, 12/03/2015 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >> а материнская плата это умеющая?
    > Почти любая десктопная AM2/AM3 плата + AMD проц серии FX потянут ECC
    > unbuffered память.

    И планки лобзиком пилить под соответствующий разъем?

     
     
  • 7.52, AlexAT (ok), 09:50, 12/03/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > И планки лобзиком пилить под соответствующий разъем?

    Разъёмы и расположение ключа у ECC/non-ECC unbuffered вполне себе одинаковые.

     
     
  • 8.78, Аноним (-), 20:12, 21/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Более того - у меня именно ECC DRAM в мамке с AM3 сокетом Даже работает Линь ... текст свёрнут, показать
     
  • 5.46, Vkni (ok), 18:32, 11/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > а материнская плата это умеющая?

    Это не совсем правильный вопрос. Дело в том, что по статистике большинство пользовательских компов - ноуты. А сколько материнских плат ноутбуков поддерживает ECC?

     
     
  • 6.53, AlexAT (ok), 09:51, 12/03/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Это не совсем правильный вопрос. Дело в том, что по статистике большинство
    > пользовательских компов - ноуты. А сколько материнских плат ноутбуков поддерживает ECC?

    AMD'шные скорее всего поддерживают - как правильно сказано, там контроллер в проце поддерживает, и пины разведены как правило все.

     
  • 5.75, NiTr0 (ok), 19:51, 13/03/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    AM3(+) - любой асус, даже самый дешманский, умеет ЕСС. Как и АМ2/939/754. У других производителей - обычно ЕСС только на топах.

    Интел - там все более запущено.

     
  • 3.17, Аноним (-), 20:57, 10/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Ну это возможно
     
  • 3.34, Аноним (-), 00:41, 11/03/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > А на домашнем компе тоже ECC прикажите юзать?

    Ну вот у меня на домашнем десктопе память с ECC. Нет, я не покупал серверные мамки. Спасибо АМД за ECC контроллер памяти в десктопном проце :)

     
  • 2.23, Аноним (-), 22:07, 10/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Если кто-то использует не ECC память в серверах или не мониторит ECC'шные
    > ошибки, то он ССЗБ.

    И что делать при возникновении ошибки? Ребутить комп автоматом?

     
     
  • 3.29, Аноним (-), 00:32, 11/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > И что делать при возникновении ошибки?

    ECC в состоянии исправить единичный переворот бита. И детектировать множественные перевороты битов в ряде случаев. Что по этому поводу делать - есть разные варианты.

     
  • 2.35, AlexAT (ok), 08:58, 11/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Проверил тулзой свой домашний "десктопный" сервер. GA-890FXA-UD5, Samsung DDR3 (не-ECC), планки по 8 гиг. 100 итераций, проблемы не выявлено. Так что дело не только в ECC. Возможно, ещё особенности контроллеров памяти и самих чипов влияют.
     
     
  • 3.63, pavlinux (ok), 05:36, 13/03/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну чо, все померялись 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...



     
  • 2.55, RomanCh (ok), 11:03, 12/03/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Простите, а никто не в курсе что ECC в большинстве случаев основано на коде Хэмминга и потому принципиально не способно детектировать чётное количество ошибок? Т.е. если у вас 2 битика перекинутся в другие состояния, то ECC это не определит.
     
     
  • 3.58, Аноним (-), 12:34, 12/03/2015 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Ошибаетесь. уважаемый, для того, чтобы ECC не отреагировало на проблему нужно не менее 4-х ошибок, причем не абы каких, а расположенных в строго определенном порядке. Дело в том, что для каждых 8 байт чексуммы строятся и по горизонтали (для каждого байта), и по вертикали (для N-го бита каждого из байтов). Именно это позволяет исправлять единичные ошибки.
     
     
  • 4.62, RomanCh (ok), 02:02, 13/03/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Ошибаетесь. уважаемый, для того, чтобы ECC не отреагировало на проблему нужно не
    > менее 4-х ошибок, причем не абы каких, а расположенных в строго
    > определенном порядке. Дело в том, что для каждых 8 байт чексуммы
    > строятся и по горизонтали (для каждого байта), и по вертикали (для
    > N-го бита каждого из байтов). Именно это позволяет исправлять единичные ошибки.

    Пруфлинк пожалуйста, на то что *все* ECC модули памяти используют описанный вами алгоритм. Простейший случай с кодом Хэмминга чётные ошибки не отлавливает.

     
     
  • 5.64, pavlinux (ok), 05:44, 13/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >> Ошибаетесь. уважаемый, для того, чтобы 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/ecc/v2_0/pg092-e

    А ваще, грубо говоря, эти алгоритмы - секрет производителей.  

     
     
  • 6.76, RomanCh (ok), 00:13, 14/03/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Сейчас код Хэминга только в школах проходят.

    Завидую вашим школам. В наших школах 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/ecc/v2_0/pg092-e

    А ведь изначально тут был текст который мне свалился в почту и в котором было написано:

    > 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 памяти по прежнему пишут про код Хэмминга.


     
  • 5.72, Аноним (-), 16:20, 13/03/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Теоретик? ECC _обязан_ по стандарту исправлять единичные ошибки и выявлять двойные. А ваш детсадовский алгоритм не позволит решить ни одну из этих задач.
     
     
  • 6.77, RomanCh (ok), 00:16, 14/03/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Теоретик? ECC _обязан_ по стандарту исправлять единичные ошибки и выявлять двойные. А
    > ваш детсадовский алгоритм не позволит решить ни одну из этих задач.

    Оо, больше ненависти дорогой анонимус! Я всего-лишь пытаюсь дойти до правды и оперировать при этом проверенными и авторитетными данными, а не мнениями "авторитетных анонимусов". Так что свои лучи любви и троллинга приберегите для кого-нибудь другого.
    Болтовню без пруфлинков по техническим вопросам я склонен игнорировать.

    PS Код Хэмминга - "мой детсадовский алгоритм", эх, о времена, о нравы...

     

  • 1.2, Аноним (-), 18:25, 10/03/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –11 +/
    > браузере Chrome

    Хромогопробелемы.

     
     
  • 2.3, Аноним (-), 18:35, 10/03/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Нет!
     
  • 2.6, Crazy Alex (ok), 18:54, 10/03/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    "Первый эксплоит позволяет организовать выполнение кода с правами ядра системы" - ничего не говорит?
     
  • 2.7, paulus (ok), 18:58, 10/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Читайте о двух проблемах:
    "Первый эксплоит позволяет организовать выполнение кода с правами ядра системы.
    Второй вариант атаки даёт возможность обойти sandbox-изоляцию Native Client в браузере Chrome (CVE-2015-0565)".
     
  • 2.30, Аноним (-), 00:33, 11/03/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >> браузере Chrome
    > Хромогопробелемы.

    Хрен тебе. Это проблемы хромого железа.

     

  • 1.9, Аноним (-), 19:23, 10/03/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    вот блин жесть...
    "Стало страшно жить до жути" (с)

     
  • 1.10, Аноним (-), 19:23, 10/03/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Косяк архитектуры. Область кода и область данных не разграничиваются.
     
     
  • 2.12, Andrew Kolchoogin (ok), 19:47, 10/03/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Все на Гарвард?-)
    Ну-ну. ;)
     
     
  • 3.13, Аноним (-), 20:22, 10/03/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Как буто это что-то плохое!
     
     
  • 4.31, Аноним (-), 00:34, 11/03/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Как буто это что-то плохое!

    Это плохое, да. Очень геморно программится и сношает мозг искусственными ограничениями.

     
     
  • 5.60, bOOster (ok), 16:52, 12/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    До С++11 ему далеко :)
     

  • 1.36, Аноним (-), 11:15, 11/03/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Гугл очень вовремя прекратил поддержку "старых" ядер линкса в хромиуме...
     
     
  • 2.37, Andrey Mitrofanov (?), 11:59, 11/03/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Гугл очень вовремя прекратил поддержку "старых" ядер линкса в хромиуме...

    Пора прекращать поддержку старых DRAM-ов[I]![/I]

     
     
  • 3.38, Аноним (-), 12:12, 11/03/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Так ведь новых-то еще нет, фактически... :)
     
  • 3.40, Аноним (-), 14:02, 11/03/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Кто-нибудь, отучите наконец уже митрофанушку выделять восклицательный знак курсивом.
     
     
  • 4.42, Andrey Mitrofanov (?), 15:39, 11/03/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Кто-нибудь, отучите наконец уже митрофанушку выделять восклицательный знак курсивом.

    Работает же! </>

     

  • 1.39, Аноним (-), 12:18, 11/03/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    А нельзя пользовательским программам запретить чистить кэш и не парить мозг?
     
     
  • 2.43, Аноним (-), 15:43, 11/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Как ты инструкцию CLFLUSH запретишь?
     
     
  • 3.44, Аноним (-), 16:25, 11/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    F0 0F C7 C8 запретили же как-то. А по-уму - интел должен был CLFLUSH сделать ограниченной, это ж если каждый процесс начнет кэш чистить - чистый ddos получится.
     
     
  • 4.47, troosh (ok), 19:04, 11/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    И как это сделать? Как повлияет на скорость JIT (.net, java и прочие)?
     
  • 4.54, Аноним (-), 10:11, 12/03/2015 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Если процесс начнет интенсивно кэш чистить — задосит он лишь себя любимого (ну, без учета открывшегося эксплойта). А то давай еще бесконечные циклы запретим? Или вообще интенсивные вычисления? Это ж если каждый процесс начнет много сложных операций выполнять — чистый ddos получится.

    И если уж на то пошло, то это создатели памяти должны были позаботиться, чтобы интенсивное чтение из нее не разрушало данные, нет? Вот только оказалось, что а) для этого надо снизить скорость доступа к памяти, б) такой сценарий редок, спасибо процессорному кэшу. Ну, они и соптимизировали: вместо правильно работающей, но дорогой вещи сделали немного неправильную, но гораздо более дешевую.

     
     
  • 5.56, Аноним (-), 11:13, 12/03/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Если у нескольких ядер общий кэш, то очистка одним процессом "своего" кэша - будет влиять негативно на другие ядра, с их собственными процессами (забиваться будет шина памяти постоянным потоком данных этого чистильщика).
     
     
  • 6.59, Аноним (-), 14:02, 12/03/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ...то есть запретить for (i = 0; i < 16; i++) { memmove(dst_bufs[i], src_bufs[i], 1024 * 1024); }, потому что оно весь кэш же угробит, да?

    Если процесс активно модифицирует память, то либо понижай его приоритет, если этот процесс для тебя маловажен, чтобы более важные процессы получали больше ресурсов; либо нет, потому что он works as intended: проворачивает большой объем нужной тебе работы, используя ресурсы процессора эффективно, т.е. для этой самой работы, отбирая эти ресурсы у остальных, менее важных, процессов.

    Тут вся проблема — дырявая абстракция, что память под высокой нагрузкой начинает вдруг ломаться неожиданным образом, и если подобрать хитрую загрузку, то она сломается выгодным кому-то (и невыгодным тебе) способом.

     
     
  • 7.66, pavlinux (ok), 06:24, 13/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    > memmove(dst_bufs[i], src_bufs[i], 1024 * 1024); }, потому что оно весь кэш
    > же угробит, да?
    > Если процесс активно модифицирует память, то либо понижай его приоритет, если этот
    > процесс для тебя маловажен, чтобы более важные процессы получали больше ресурсов;
    > либо нет, потому что он works as intended: проворачивает большой объем
    > нужной тебе работы, используя ресурсы процессора эффективно, т.е. для этой самой
    > работы, отбирая эти ресурсы у остальных, менее важных, процессов.
    > Тут вся проблема — дырявая абстракция, что память под высокой нагрузкой начинает
    > вдруг ломаться неожиданным образом, и если подобрать хитрую загрузку, то она
    > сломается выгодным кому-то (и невыгодным тебе) способом.

    Спыцыалисты... йоптя...

     
  • 3.65, pavlinux (ok), 06:00, 13/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Как ты инструкцию CLFLUSH запретишь?

    Как два байта об асфальт

    1. указываешь ядру при загрузке "noclflush"
    Тока в обморок не падайте, есть ещо штук 5-6 инструкций для сброса.
    В случае ядра линя будет использоваться wbinvd

    2.



    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)


    ну и далее по тексту ...

     
     
  • 4.68, Аноним (-), 13:20, 13/03/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Эмм... ну не будет ядро использовать 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? Или предлагаешь во всех программах его выпатчить? Синхронизация от этого ни у кого не убьется? Специалист...

     
     
  • 5.69, pavlinux (ok), 14:43, 13/03/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Эмм... ну не будет ядро использовать 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 та же хрень, только старая и сбрасывает все кэши.
    С этой инструкцией только стабильнее будет, чуть тормознутее,
    но лучше, особо на многотредовых приложениях с общими переменными.

     
     
  • 6.70, Аноним (-), 15:02, 13/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Да, я в курсе. И если в бинарнике лежат байты 0F AE в секции кода, и исполнение дойдет до них — то процессор их выполнит (это CLFLUSH), и ничего ОС с этим не сделает. А они там лежать будут, потому что ОС не трассирует (как правило) выполнение пользовательского кода, а исправить произвольный код перед запуском на нужный на практике нереально.
     

  • 1.48, Ilya Indigo (ok), 21:40, 11/03/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вот бабла срубит автор второго эксплоита от Google...
     
     
  • 2.61, Аноним (-), 21:24, 12/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    А он там и работает. как раз над nacl sandbox'ом
     

  • 1.84, Аноним (-), 11:04, 06/06/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Какое же халтурное дерьмищще! нам подсовывают.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру