The OpenNET Project / Index page

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



"Атака по восстановлению содержимого памяти при помощи страни..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Атака по восстановлению содержимого памяти при помощи страни..."  +/
Сообщение от opennews (?), 09-Янв-19, 19:14 
Группа исследователей безопасности, из которых несколько участвовали в выявлении первых уязвимостей Meltdown и Spectre, разработали (https://arxiv.org/pdf/1901.01161.pdf) новый вид атаки по сторонним каналам, проводимой на основе анализа содержимого
страничного кэша (page cache), в котором содержится информация, полученная в результате обращения операционной системы к диску, SSD-накопителю и другим блочным устройствам. В отличие от атак Spectre, новая уязвимость не вызвана аппаратными проблемами, а касается только программных реализаций страничного кэша и проявляется в Linux (CVE-2019-5489 (https://security-tracker.debian.org/tracker/CVE-2019-5489)), Windows и вероятно во многих других операционных системах. Для ядра Linux исправление уже доступно (https://lkml.org/lkml/2019/1/5/104) в виде патча (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...). В Windows 10 проблема устранена в тестовой сборке (Insider Preview Build) 18305.

Через манипуляции с системными вызовами mincore (http://man7.org/linux/man-pages/man2/mincore.2.html) (Linux) и QueryWorkingSetEx (https://docs.microsoft.com/en-us/windows/desktop/api/psapi/n...) (Windows), позволяющими определить наличие страницы памяти в системном страничном кэше, локальный непривилегированный атакующий может отслеживать некоторые обращения других процессов к памяти. Атака позволяет отслеживать доступ на уровне 4 килобайтовых блоков с временным разрешением в 2 микросекунды в Linux (6.7 измерений в секунду) и 446 наносекунд в Windows (223 измерений в секунду).


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

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

Среди продемонстрированных исследователями практических применений атаки на локальную систему упоминается создание канала передачи данных из полностью изолированных sandbox-окружений, воссоздание выводимых на экран элементов интерфейса (например, диалогов аутентификации), определение задержек при нажатии клавиш и восстановление автоматически генерируемых приложением phpMyFAQ  временных паролей. Более того, предложен сценарий гипотетической удалённой атаки, позволяющей локально запущенному вредоносному процессу скрыто передать данные вовне через канал связи, организованный при помощи манипуляцией со страничным кэшем (принимающая сторона определяет данные через измерение задержек при отдаче http-сервером Apache частей публично доступных файлов).


URL: https://www.openwall.com/lists/oss-security/2019/01/07/1
Новость: https://www.opennet.ru/opennews/art.shtml?num=49927

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по ответам | RSS]

1. "Представлена атака по восстановлению содержимого памяти при ..."  –3 +/
Сообщение от Иван Семеныч (?), 09-Янв-19, 19:14 
Столмен был прав . . .
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

3. "Атака по определению содержимого памяти процессов при помощи..."  +3 +/
Сообщение от Olehemail (ok), 09-Янв-19, 19:21 
В чем суть уязвимости?

Что дает знание есть страница в кеше или нет?
С тем самым подходом можно:
- определять запущенна программа или нет;
- по времени рендеринга страницы opennet.net можно понять была ли она в кеше или нет.
...

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

4. "Атака по определению состояния памяти процессов при помощи с..."  –36 +/
Сообщение от Anon_Erohin (?), 09-Янв-19, 19:48 
По-моему давно пора выкидывать на свалку истории C, время пришло за молодым и современным решением - Rust. Как по мне сейчас в него надо вкладывать финансирование для полировки и стабилизации чем раздавать(отмывать и пилить) бюджеты опен сорс организаций на какие-то там кде или другие putty, нотепады...
Иначе будет поздно, даже совсем скоро. Я давно об этом пишу, но похожу мало кто это понимает.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

5. "Атака по определению содержимого памяти процессов при помощи..."  +2 +/
Сообщение от Cradle (?), 09-Янв-19, 19:49 
использовать как триггер для запуска аттаки другого типа, чтобы не светиться раньше времени
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

6. "Атака по определению состояния памяти процессов при помощи с..."  +6 +/
Сообщение от Cradle (?), 09-Янв-19, 19:49 
а что, раст кэшем не пользуется?
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

7. "Атака по определению содержимого памяти процессов при помощи..."  +/
Сообщение от Аноним (7), 09-Янв-19, 19:50 
Если после вытеснения из кэша страница остаётся в физической памяти, значит данные в этой странице находились не только в кэше, но и виртуальной памяти какого-то процесса.
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

8. "Атака по определению содержимого памяти процессов при помощи..."  +/
Сообщение от Аноним (8), 09-Янв-19, 20:08 
> после вытеснения из кэша страница остаётся в физической памяти

Если под кешем вы имеете ввиду страничный кеш, то как это?

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

9. "Атака по определению состояния памяти процессов при помощи с..."  +1 +/
Сообщение от Аноним (9), 09-Янв-19, 20:11 
а чего сразу не js ?
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

10. "Атака по определению содержимого памяти процессов при помощи..."  +/
Сообщение от Аноним (7), 09-Янв-19, 20:11 
Флудят дисковой активностью или всплески потребления памяти, близкие к OOM, создают.
Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

11. "Атака по определению содержимого памяти процессов при помощи..."  +/
Сообщение от Аноним (7), 09-Янв-19, 20:16 
В памяти остаётся так как дублирующиеся страницы дедуплицируются и хранится одна копия повторяющейся страницы из страничного кэша и памяти приложения.
Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

12. "Атака по определению состояния памяти процессов при помощи с..."  +1 +/
Сообщение от Аноним (12), 09-Янв-19, 20:49 
Бред
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

13. "Атака по определению состояния памяти процессов при помощи с..."  +/
Сообщение от Аноним (13), 09-Янв-19, 20:51 
> Я давно об этом пишу, но похожу мало кто это понимает.

А может быть, про перспективы Rust почти все давно всё поняли, а до сих пор чего-то не понимаете как раз Вы?

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

14. "Атака по определению содержимого памяти процессов при помощи..."  +/
Сообщение от letsmac (ok), 09-Янв-19, 20:52 
Перевел так:

Если страница недавно была в кэше - значит данные в физической памяти еще некоторое время назад были валидными и использовались рабочим процессом.  

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

15. "Атака по определению состояния памяти процессов при помощи с..."  +/
Сообщение от letsmac (ok), 09-Янв-19, 20:54 
Там вроде как используется очистка памяти при освобождении. С/С++ то-же так умеет.
Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

16. "Атака по определению состояния памяти процессов при помощи с..."  –10 +/
Сообщение от Anon_Erohin (?), 09-Янв-19, 21:03 
Именно, только в С/C++ это нужно делать вручную, я думаю мало кто забивает нулями после память после ее освобождения. Неразобравшись сразу заминусовали, ох уж эти диванные программисты.
Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

17. "Атака по определению состояния памяти процессов при помощи с..."  +2 +/
Сообщение от Петровичус (?), 09-Янв-19, 21:12 
JS для прикладухи, САПР, итд.
Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

18. "Атака по определению состояния памяти процессов при помощи с..."  +4 +/
Сообщение от Аноним84701 (ok), 09-Янв-19, 21:13 
> Именно, только в С/C++ это нужно делать вручную, я думаю мало кто
> забивает нулями после память после ее освобождения. Неразобравшись сразу заминусовали, ох уж эти диванные программисты.

Религиозные убеждения не позволяют использовать модифицированную версию аллокатора, делающую это при вызове free/delete/whatever?
Кстати, удачи таким макаром из программы вычистить системный страничный кэш …

В общем, первый вброс был совсем не плох, на нем бы кое-кому и остановиться …


Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

19. "Атака по определению состояния памяти процессов при помощи с..."  –1 +/
Сообщение от letsmac (ok), 09-Янв-19, 21:35 
>>Кстати, удачи таким макаром из программы вычистить системный страничный кэш …

Что такое системный страничный кэш? TLB ?

>> делающую это при вызове free/delete/whatever?

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

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

20. "Атака по определению состояния памяти процессов при помощи с..."  +2 +/
Сообщение от Аноним (20), 09-Янв-19, 21:41 
>Для ядра Linux исправление уже доступно в виде патча.

Ещё -50% производительности?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

21. "Атака по определению состояния памяти процессов при помощи с..."  –1 +/
Сообщение от Аноним (21), 09-Янв-19, 21:47 
И как всю эту радость теперь отключать?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

22. "Атака по определению состояния памяти процессов при помощи с..."  +/
Сообщение от Аноним (22), 09-Янв-19, 21:47 
Ждём отдельный проц для ядра и привилегированных процессов, и отдельный для юзерленда.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

23. "Атака по определению состояния памяти процессов при помощи с..."  +/
Сообщение от Аноним (23), 09-Янв-19, 21:56 
А есть процессоры без кеша?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

24. "Атака по определению состояния памяти процессов при помощи с..."  +/
Сообщение от Аноним84701 (ok), 09-Янв-19, 21:58 
>>>Кстати, удачи таким макаром из программы вычистить системный страничный кэш …
> Что такое системный страничный кэш? TLB ?

Из новости:
>> проводимой на основе анализа содержимого  страничного кэша (page cache), в котором содержится информация, полученная в результате обращения операционной системы к диску,

.
> Про это уже много страдательных статей. Главная причина - оно же тормозное довольно таки.

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

Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

25. "Атака по определению состояния памяти процессов при помощи с..."  –1 +/
Сообщение от letsmac (ok), 09-Янв-19, 22:11 
>>>> проводимой на основе анализа содержимого  страничного кэша (page cache), в котором содержится информация, полученная в результате обращения операционной системы к диску,

Возможно переводчик не так выразился :

mincore - determine whether pages are resident in memory

QueryWorkingSetEx - Retrieves extended information about the pages at specific virtual addresses in the address space of the specified process.

ТЕ просто эти функции смотрят страница в RAM или сброшена на диск (page fault). В подкачке реально можно много чего нарыть, но подкачка в современных системах..... Там надо постараться, чтобы кэш (!) при наличии свободной RAM (!) засвопился. Если только принудительно сбрасывать, так можно да согласен.

Пошел перечитывать Танненбаума, начал забывать базис.

Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

26. "Атака по определению состояния памяти процессов при помощи с..."  +/
Сообщение от letsmac (ok), 09-Янв-19, 22:12 
В САПРе лисп и тикль по большей части.  
Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

27. "Атака по определению состояния памяти процессов при помощи с..."  +/
Сообщение от letsmac (ok), 09-Янв-19, 22:13 
Отключив подкачку.
Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

28. "Атака по определению состояния памяти процессов при помощи с..."  +2 +/
Сообщение от Аноним (28), 09-Янв-19, 22:15 
Они неэффективны.
Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

29. "Атака по определению состояния памяти процессов при помощи с..."  +3 +/
Сообщение от letsmac (ok), 09-Янв-19, 22:20 
ARM cortex-m, AVR, i8051 и прочие.  
Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

30. "Атака по определению состояния памяти процессов при помощи с..."  –1 +/
Сообщение от proninyaroslavemail (ok), 09-Янв-19, 22:21 
В системной программировании (вместо С) или замена C++ (как язык общего назначения, в том числе бэкенд)? В целом он претендует на оба направления, но только время покажет какую нишу он займёт.
Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

32. "Атака по определению состояния памяти процессов при помощи с..."  –2 +/
Сообщение от Иван Семеныч (?), 09-Янв-19, 22:24 
JS -- тот же лисп, вид сбоку.
Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

33. "Атака по определению состояния памяти процессов при помощи с..."  +1 +/
Сообщение от Аноним (33), 09-Янв-19, 23:08 
Время покажет, что никакую.
Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

34. "Атака по определению состояния памяти процессов при помощи с..."  +1 +/
Сообщение от Michael Shigorinemail (ok), 09-Янв-19, 23:43 
> Я давно об этом пишу, но похожу мало кто это понимает.

Всё потому, что Вы пишете "об этом", а не это.

Идите и пишите своё ядро.  Заодно, глядишь, поймёте, в чём вообще дело было -- лет так через пять -- и почему с любым rust, .net, java или ещё чем такие проблемы _в лучшем случае_ останутся на месте (пока будете бороться с худшим случаем, если доберётесь).

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

35. "Атака по определению состояния памяти процессов при помощи с..."  +1 +/
Сообщение от Michael Shigorinemail (ok), 09-Янв-19, 23:45 
> Именно, только в С/C++ это нужно делать вручную, я думаю мало кто
> забивает нулями после память после ее освобождения. Неразобравшись

...вот и надо не "думать", а разбираться, прежде чем стремительно чушь нести.

Ключевые слова -- memory sanitization.  РД никто Вам (как и мне) не даст, видимо, но хватит и без них.

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

36. "Атака по определению состояния памяти процессов при помощи с..."  +2 +/
Сообщение от Michael Shigorinemail (ok), 09-Янв-19, 23:47 
>> page cache
> А есть процессоры без кеша?

Это не про тот кэш.

Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

37. "Атака по определению состояния памяти процессов при помощи с..."  +2 +/
Сообщение от Аноним (37), 10-Янв-19, 00:08 
> JS -- тот же лисп, вид сбоку.

Это НЕДОДЕЛАННЫЙ лисп сбоку. Никаких рестартов, никаких макросов. Неуниверсальный синтаксис, из-за чего возникает необходимость костылей типа промисов.

Хотя кому я это пишу...

Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

38. "Атака по определению состояния памяти процессов при помощи с..."  +/
Сообщение от Аноним (37), 10-Янв-19, 00:10 
> Идите и пишите своё ядро

Не прокатит. Пока он "пишет своё ядро" на расте, раст выйдет из моды, и он будет писать о расте то же самое, что сейчас пишет о c/c++. Он это понимает, поэтому и смысла не видит вкладывать свои ресурсы во что-то кроме комментов на опеннете.

Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

39. "Атака по определению состояния памяти процессов при помощи с..."  –1 +/
Сообщение от Аноним (37), 10-Янв-19, 00:14 
> Ещё -50% производительности?

И небось опять не в виде ifdef-ов, а с runtime-проверкой, на которую приходится половина этого снижения производительности.

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

40. "Атака по определению состояния памяти процессов при помощи с..."  +/
Сообщение от Аноним (37), 10-Янв-19, 00:17 
> В системной программировании (вместо С)

Метит, но не выстрелит. Как язык C намного проще, и не только в плане синтаксиса. Некоторые считают, что это важно. Меньше абстракций - ближе к железу - производительнее/предсказуемее/надёжнее.

Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

42. "Атака по определению состояния памяти процессов при помощи с..."  +/
Сообщение от Эш Уильямс (?), 10-Янв-19, 01:41 
Это софтварный кеш ОС для увеличение отзывчивости при увеличении нагрузки.
Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

43. "Атака по определению состояния памяти процессов при помощи с..."  +4 +/
Сообщение от Какаянахренразница (ok), 10-Янв-19, 05:21 
Шо, опять???
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

44. "Атака по определению состояния памяти процессов при помощи с..."  +/
Сообщение от КО (?), 10-Янв-19, 10:07 
>По-моему давно пора выкидывать на свалку истории C

Всецело поддерживаю, полагаться на то, что компютер сам что-то доделает за тебя - путь к потенциальным проблемам. Писать надо сразу в машинных кодах! :)

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

45. "Атака по определению состояния памяти процессов при помощи с..."  +/
Сообщение от КО (?), 10-Янв-19, 10:10 
Каждой задаче по своему компьютеру, а буфер обмена через облако :)
Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

46. "Атака по определению состояния памяти процессов при помощи с..."  –1 +/
Сообщение от Andrey Mitrofanov (?), 10-Янв-19, 10:12 
> Ждём отдельный проц для ядра и привилегированных процессов, и отдельный для юзерленда.

Не жди!  Интель с Таненбаумом -- уже.

Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

47. "Атака по определению содержимого памяти процессов при помощи..."  +/
Сообщение от КО (?), 10-Янв-19, 10:17 
>Что дает знание есть страница в кеше или нет?

Если страница в памяти, значит ее можно утащить через всякие спектры с мельдонием.

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

48. "Атака по определению состояния памяти процессов при помощи с..."  +/
Сообщение от Аноним (48), 10-Янв-19, 10:52 
-50000%
Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

49. "Атака по определению состояния памяти процессов при помощи с..."  +/
Сообщение от Аноним (49), 10-Янв-19, 10:59 
>По-моему давно пора выкидывать на свалку истории C, время пришло за молодым и современным решением - Rust.

Господа хрустисты, ваш Хруст в решении этой конкретной проблемы не поможет совершенно, с точность до вообще. И Оберон с Брейнфаком тоже не помогут.

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

50. "Атака по определению состояния памяти процессов при помощи с..."  +/
Сообщение от Аноним (49), 10-Янв-19, 11:25 
>В отличие от атак Spectre, новая уязвимость не вызвана аппаратными проблемами, а касается только программных реализаций страничного кэша

Так что, с чего бы это? Это не аппаратную уязвимость вокруг обходить. Что-то раньше при латании чисто софтовых уязвимостей никто не ныл про снижение производительности.

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

51. "Атака по определению состояния памяти процессов при помощи с..."  –1 +/
Сообщение от Аноним (49), 10-Янв-19, 11:26 
Сделали уязвимый Intel ME?
Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

52. "Атака по определению содержимого памяти процессов при помощи..."  +/
Сообщение от Аноним (52), 10-Янв-19, 11:46 
Не понятно? Вот в этом и суть: надо просто бояться =)
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

53. "Атака по определению состояния памяти процессов при помощи с..."  +1 +/
Сообщение от Аноним (52), 10-Янв-19, 11:51 
Пузырь надувают, пока он не лопнет.
Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

54. "Атака по определению содержимого памяти процессов при помощи..."  +/
Сообщение от newbie (??), 10-Янв-19, 13:04 
Есть такая игра в steam, brainout называется, вот у меня такое впечатление, что она этим и занимается когда я в нее играю ;) через некоторое время рывки всякие и подфриживания, а потом дикий сброс всего из памяти в своп и зависание, правда она на java. Выделение -Xms -Xmn -Xmx не помогают. Что только не делал, думал что проблема в ACPI багах, в общем я сбился с толку пытаясь пофиксить это поведение, по сути просто игра так устроена, что вызывает более быстрые фризы и зависания, а вот в чем суть проблемы под Linux без понятия, вот несколько вещей которые пробовал, но все сводится к одному, в конечном итоге через некоторое время комп виснет намертво, биос шил последний, пробовал DSDT править (исправить исправил с горем пополам, но некоторых методов просто не существует и как их туда дописать я не знаю), в итоге вернулся к обыкновенным настройкам:

acpi_osi=Linux acpi=force acpi_enforce_resources=lax radeon.dpm=1 radeon.audio=1 hpet=force clocksource=hpet pci=ioapicreroute,realloc acpi_sleep=old_ordering"

#pcie_aspm=off intel_idle.max_cstate=0 processor.max_cstate=0 intel_pstate=disable acpi_sleep=old_ordering"
#acpi_osi=Linux acpi=force acpi_enforce_resources=lax radeon.dpm=1 radeon.audio=1"
#acpi=off hpet=disable pcie_aspm=off intel_idle.max_cstate=0 processor.max_cstate=0 intel_pstate=disable"
#acpi_osi=Linux acpi=force acpi_enforce_resources=lax radeon.dpm=1 radeon.audio=1 hpet=force clocksource=hpet irqpoll pci=ioapicreroute,assign-busses,nocrs,routeirq,nobfsort,pcie_bus_peer2peer,realloc pcie_aspm=off intel_idle.max_cstate=0 processor.max_cstate=0 intel_pstate=disable acpi_sleep=old_ordering"

#CPU issues mitigation produces complete freeze?
#pti=off l1tf=off spectre_v2=off spec_store_bypass_disable=off
#check for possible dependencies between CPU hang
#intel_pstate=disable intel_idle.max_cstate=0 processor.max_cstate=0

#cat /sys/devices/system/clocksource/clocksource0/available_clocksource
#tsc hpet acpi_pm
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
#irqpoll

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

55. "Атака по определению состояния памяти процессов при помощи с..."  +1 +/
Сообщение от КО (?), 11-Янв-19, 10:42 
>Именно, только в С/C++ это нужно делать вручную, я думаю мало кто забивает нулями после память после ее освобождения

Забивать память 0 _после_ освобождения это покруче разименования 0 указателя. :)

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

56. "Атака по определению состояния памяти процессов при помощи с..."  +/
Сообщение от Аноним (56), 11-Янв-19, 13:59 
Давайте затормозим кэш что никто не смог воспользоваться этой "уязвимостью".
Или лучше вообще отключим
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

57. "Атака по определению состояния памяти процессов при помощи с..."  +1 +/
Сообщение от Andrey Mitrofanov (?), 11-Янв-19, 14:02 
> Давайте затормозим кэш что никто не смог
> Или лучше вообще отключим

Пральна, ящитаю!  Прекратить читать с "диску, SSD-накопителю и другим блочным устройствам" в память  --  от этого одни уязвимости. >7<

Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

58. "Атака по определению состояния памяти процессов при помощи с..."  +/
Сообщение от Эш Уильямс (?), 11-Янв-19, 19:25 
А как же уязвимость RowHammer в DDR и SSD?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору


Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Спонсоры:
Слёрм
Inferno Solutions
Hosting by Ihor
Хостинг:

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