|
| 1.3, Oleh (ok), 19:21, 09/01/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
 В чем суть уязвимости?
Что дает знание есть страница в кеше или нет?
С тем самым подходом можно:
- определять запущенна программа или нет;
- по времени рендеринга страницы opennet.net можно понять была ли она в кеше или нет.
...
| | |
| |
| 2.5, Cradle (?), 19:49, 09/01/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
использовать как триггер для запуска аттаки другого типа, чтобы не светиться раньше времени
| | |
| 2.7, Аноним (7), 19:50, 09/01/2019 [^] [^^] [^^^] [ответить]
| +/– |
Если после вытеснения из кэша страница остаётся в физической памяти, значит данные в этой странице находились не только в кэше, но и виртуальной памяти какого-то процесса.
| | |
| |
| 3.8, Аноним (8), 20:08, 09/01/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> после вытеснения из кэша страница остаётся в физической памяти
Если под кешем вы имеете ввиду страничный кеш, то как это?
| | |
| |
| 4.10, Аноним (7), 20:11, 09/01/2019 [^] [^^] [^^^] [ответить]
| +/– |
Флудят дисковой активностью или всплески потребления памяти, близкие к OOM, создают.
| | |
| |
| 5.54, newbie (??), 13:04, 10/01/2019 [^] [^^] [^^^] [ответить] | +/– | Есть такая игра в steam, brainout называется, вот у меня такое впечатление, что ... большой текст свёрнут, показать | | |
|
| 4.11, Аноним (7), 20:16, 09/01/2019 [^] [^^] [^^^] [ответить]
| +/– |
В памяти остаётся так как дублирующиеся страницы дедуплицируются и хранится одна копия повторяющейся страницы из страничного кэша и памяти приложения.
| | |
|
| 3.14, letsmac (ok), 20:52, 09/01/2019 [^] [^^] [^^^] [ответить]
| +/– |
 Перевел так:
Если страница недавно была в кэше - значит данные в физической памяти еще некоторое время назад были валидными и использовались рабочим процессом.
| | |
|
| 2.47, КО (?), 10:17, 10/01/2019 [^] [^^] [^^^] [ответить]
| +/– | |
>Что дает знание есть страница в кеше или нет?
Если страница в памяти, значит ее можно утащить через всякие спектры с мельдонием.
| | |
|
| 1.4, Anon_Erohin (?), 19:48, 09/01/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –36 +/– |
По-моему давно пора выкидывать на свалку истории C, время пришло за молодым и современным решением - Rust. Как по мне сейчас в него надо вкладывать финансирование для полировки и стабилизации чем раздавать(отмывать и пилить) бюджеты опен сорс организаций на какие-то там кде или другие putty, нотепады...
Иначе будет поздно, даже совсем скоро. Я давно об этом пишу, но похожу мало кто это понимает.
| | |
| |
| |
| 3.15, letsmac (ok), 20:54, 09/01/2019 [^] [^^] [^^^] [ответить]
| +/– |
Там вроде как используется очистка памяти при освобождении. С/С++ то-же так умеет.
| | |
| |
| 4.16, Anon_Erohin (?), 21:03, 09/01/2019 [^] [^^] [^^^] [ответить]
| –10 +/– |
Именно, только в С/C++ это нужно делать вручную, я думаю мало кто забивает нулями после память после ее освобождения. Неразобравшись сразу заминусовали, ох уж эти диванные программисты.
| | |
| |
| 5.18, Аноним84701 (ok), 21:13, 09/01/2019 [^] [^^] [^^^] [ответить]
| +4 +/– |
 > Именно, только в С/C++ это нужно делать вручную, я думаю мало кто
> забивает нулями после память после ее освобождения. Неразобравшись сразу заминусовали, ох уж эти диванные программисты.
Религиозные убеждения не позволяют использовать модифицированную версию аллокатора, делающую это при вызове free/delete/whatever?
Кстати, удачи таким макаром из программы вычистить системный страничный кэш …
В общем, первый вброс был совсем не плох, на нем бы кое-кому и остановиться …
| | |
| |
| 6.19, letsmac (ok), 21:35, 09/01/2019 [^] [^^] [^^^] [ответить]
| –1 +/– | |
>>Кстати, удачи таким макаром из программы вычистить системный страничный кэш …
Что такое системный страничный кэш? TLB ?
>> делающую это при вызове free/delete/whatever?
Про это уже много страдательных статей. Главная причина - оно же тормозное довольно таки.
| | |
| |
| 7.24, Аноним84701 (ok), 21:58, 09/01/2019 [^] [^^] [^^^] [ответить]
| +/– |
>>>Кстати, удачи таким макаром из программы вычистить системный страничный кэш …
> Что такое системный страничный кэш? TLB ?
Из новости:
>> проводимой на основе анализа содержимого страничного кэша (page cache), в котором содержится информация, полученная в результате обращения операционной системы к диску,
.
> Про это уже много страдательных статей. Главная причина - оно же тормозное довольно таки.
Ну дык -- не я предлагаю очищать память после освобождения (хотя автоматически, хоть ручками).
| | |
|
|
| 5.35, Michael Shigorin (ok), 23:45, 09/01/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > Именно, только в С/C++ это нужно делать вручную, я думаю мало кто
> забивает нулями после память после ее освобождения. Неразобравшись
...вот и надо не "думать", а разбираться, прежде чем стремительно чушь нести.
Ключевые слова -- memory sanitization. РД никто Вам (как и мне) не даст, видимо, но хватит и без них.
| | |
| 5.55, КО (?), 10:42, 11/01/2019 [^] [^^] [^^^] [ответить]
| +1 +/– | |
>Именно, только в С/C++ это нужно делать вручную, я думаю мало кто забивает нулями после память после ее освобождения
Забивать память 0 _после_ освобождения это покруче разименования 0 указателя. :)
| | |
|
|
|
| |
| |
| |
| |
| 6.37, Аноним (37), 00:08, 10/01/2019 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> JS -- тот же лисп, вид сбоку.
Это НЕДОДЕЛАННЫЙ лисп сбоку. Никаких рестартов, никаких макросов. Неуниверсальный синтаксис, из-за чего возникает необходимость костылей типа промисов.
Хотя кому я это пишу...
| | |
|
|
|
|
| 2.13, Аноним (13), 20:51, 09/01/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> Я давно об этом пишу, но похожу мало кто это понимает.
А может быть, про перспективы Rust почти все давно всё поняли, а до сих пор чего-то не понимаете как раз Вы?
| | |
| |
| 3.30, proninyaroslav (ok), 22:21, 09/01/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
 В системной программировании (вместо С) или замена C++ (как язык общего назначения, в том числе бэкенд)? В целом он претендует на оба направления, но только время покажет какую нишу он займёт.
| | |
| |
| 4.40, Аноним (37), 00:17, 10/01/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> В системной программировании (вместо С)
Метит, но не выстрелит. Как язык C намного проще, и не только в плане синтаксиса. Некоторые считают, что это важно. Меньше абстракций - ближе к железу - производительнее/предсказуемее/надёжнее.
| | |
|
|
| 2.34, Michael Shigorin (ok), 23:43, 09/01/2019 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Я давно об этом пишу, но похожу мало кто это понимает.
Всё потому, что Вы пишете "об этом", а не это.
Идите и пишите своё ядро. Заодно, глядишь, поймёте, в чём вообще дело было -- лет так через пять -- и почему с любым rust, .net, java или ещё чем такие проблемы _в лучшем случае_ останутся на месте (пока будете бороться с худшим случаем, если доберётесь).
| | |
| |
| 3.38, Аноним (37), 00:10, 10/01/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> Идите и пишите своё ядро
Не прокатит. Пока он "пишет своё ядро" на расте, раст выйдет из моды, и он будет писать о расте то же самое, что сейчас пишет о c/c++. Он это понимает, поэтому и смысла не видит вкладывать свои ресурсы во что-то кроме комментов на опеннете.
| | |
|
| 2.44, КО (?), 10:07, 10/01/2019 [^] [^^] [^^^] [ответить]
| +/– | |
>По-моему давно пора выкидывать на свалку истории C
Всецело поддерживаю, полагаться на то, что компютер сам что-то доделает за тебя - путь к потенциальным проблемам. Писать надо сразу в машинных кодах! :)
| | |
| 2.49, Аноним (49), 10:59, 10/01/2019 [^] [^^] [^^^] [ответить]
| +/– | |
>По-моему давно пора выкидывать на свалку истории C, время пришло за молодым и современным решением - Rust.
Господа хрустисты, ваш Хруст в решении этой конкретной проблемы не поможет совершенно, с точность до вообще. И Оберон с Брейнфаком тоже не помогут.
| | |
|
| 1.20, Аноним (20), 21:41, 09/01/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– | |
>Для ядра Linux исправление уже доступно в виде патча.
Ещё -50% производительности?
| | |
| |
| 2.39, Аноним (37), 00:14, 10/01/2019 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Ещё -50% производительности?
И небось опять не в виде ifdef-ов, а с runtime-проверкой, на которую приходится половина этого снижения производительности.
| | |
| 2.50, Аноним (49), 11:25, 10/01/2019 [^] [^^] [^^^] [ответить]
| +/– | |
>В отличие от атак Spectre, новая уязвимость не вызвана аппаратными проблемами, а касается только программных реализаций страничного кэша
Так что, с чего бы это? Это не аппаратную уязвимость вокруг обходить. Что-то раньше при латании чисто софтовых уязвимостей никто не ныл про снижение производительности.
| | |
|
| 1.22, Аноним (22), 21:47, 09/01/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Ждём отдельный проц для ядра и привилегированных процессов, и отдельный для юзерленда.
| | |
| |
| 2.45, КО (?), 10:10, 10/01/2019 [^] [^^] [^^^] [ответить]
| +/– |
Каждой задаче по своему компьютеру, а буфер обмена через облако :)
| | |
| 2.46, Andrey Mitrofanov (?), 10:12, 10/01/2019 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Ждём отдельный проц для ядра и привилегированных процессов, и отдельный для юзерленда.
Не жди! Интель с Таненбаумом -- уже.
| | |
|
| 1.56, Аноним (56), 13:59, 11/01/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Давайте затормозим кэш что никто не смог воспользоваться этой "уязвимостью".
Или лучше вообще отключим
| | |
| |
| 2.57, Andrey Mitrofanov (?), 14:02, 11/01/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Давайте затормозим кэш что никто не смог
> Или лучше вообще отключим
Пральна, ящитаю! Прекратить читать с "диску, SSD-накопителю и другим блочным устройствам" в память -- от этого одни уязвимости. >7<
| | |
|
|
