The OpenNET Project / Index page

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



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

"Уязвимости в подсистеме eBPF, позволяющие обойти защиту от атак класса Spectre"  +/
Сообщение от opennews (??), 22-Июн-21, 16:33 
В ядре Linux выявлена уязвимость (CVE-2021-33624), позволяющая использовать подсистему еBPF для обхода защиты от уязвимостей класса Spectre, дающих возможность определить содержимое памяти  в результате создания условий для спекулятивного выполнения определённых операций. Для атаки Spectre требуется наличие в привилегированном коде определённой последовательности команд, приводящих к спекулятивному выполнению инструкций. Через манипуляцию с передаваемыми для выполнения BPF-программами можно добиться генерации подобных инструкций в еBPF и добиться утечки по сторонним каналам содержимого памяти ядра и произвольных областей физической памяти...

Подробнее: https://www.opennet.dev/opennews/art.shtml?num=55371

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

Оглавление

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


1. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  –12 +/
Сообщение от Аноним (1), 22-Июн-21, 16:33 
Почему вы до сих пор не на BSD? Очевидно же, что там таких уязвимостей нет.
Ответить | Правка | Наверх | Cообщить модератору

6. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +16 +/
Сообщение от OnTheEdge (ok), 22-Июн-21, 16:45 
как и нормальной поддержки туевой хучи оборудования, к сожалению
Ответить | Правка | Наверх | Cообщить модератору

20. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  –4 +/
Сообщение от Аноним (20), 22-Июн-21, 17:14 
огласите весь список что на сервер надо
Ответить | Правка | Наверх | Cообщить модератору

26. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +14 +/
Сообщение от OnTheEdge (ok), 22-Июн-21, 17:21 
а я по предположению анона выше должен с сервера эту новость читать?
Ответить | Правка | Наверх | Cообщить модератору

44. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  –4 +/
Сообщение от Аноним (44), 22-Июн-21, 18:36 
Нет же. Сервер у вас в окошке Pytty будет, а новость в бжественной Десяточке читайте.
Ответить | Правка | Наверх | Cообщить модератору

71. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +4 +/
Сообщение от Аноним (-), 22-Июн-21, 20:33 
> Нет же. Сервер у вас в окошке Pytty будет,
> а новость в бжественной Десяточке читайте.
> бжественной Десяточке

Очередной WSLщик-Петросян совсем не палится ...
https://i.postimg.cc/SxVZBVyD/2021-06-22-19-29.png
"И вот так - у вас все!"(с)


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

100. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Брат Анон (ok), 23-Июн-21, 08:45 
Как?
Ответить | Правка | Наверх | Cообщить модератору

137. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Аноним (-), 23-Июн-21, 12:49 
> Как?

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

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

183. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Брат Анон (ok), 24-Июн-21, 17:26 
> как обычно, промахнуться своими фантазиями мимо реальности
> (или где там на скрине можно путти с десяточкой увидеть?)

Как на чужом компе это можно было разглядеть?))


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

32. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  –5 +/
Сообщение от Жироватт (ok), 22-Июн-21, 17:42 
На виртуальный сервер с неким набором "стандартного эмулируемого железа - без проблем.
Ставишь в качестве простого гипервизора на реальном серверном (сервернее некуда)железе - хренушки, сказали заюшки.
Ставишь её в виртуалку, но немного недефолтным железом - оппа, у нас тут рулеточка, что заведется сразу, что - с полупинка, а что - надо кормить линуксовыми дровами!
Хочешь превратить списанный дроволет в легких нетребовательный сервер? Ха! Рулетка еще более русская, запас секса обеспечен.
Ну может хотя бы на нетребовательную, стандартную роутеровскую досточку? Фигвам, называется, накатывается линуксячий openwrt.
Какие будут оправдания?
Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

35. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  –2 +/
Сообщение от Аноним (-), 22-Июн-21, 17:51 
> Жироватт
> На виртуальный сервер с неким набором "стандартного эмулируемого железа - без проблем.
> Ставишь в качестве простого гипервизора на реальном серверном (сервернее некуда)железе
> - хренушки, сказали заюшки.
> Ставишь её в виртуалку, но немного недефолтным железом - оппа, у нас
> тут рулеточка, что заведется сразу, что - с полупинка, а что
> - надо кормить линуксовыми дровами!

...
> Какие будут оправдания?

Ты в нике использовал букву 'и' вместо положенного 'ы' - какие еще могут быть "оправдания"?

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

68. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  –1 +/
Сообщение от Dzen Python (ok), 22-Июн-21, 19:55 
Ты второе и третье перепутал.
Как вспомню, как я любился с сетевухами и матерями на нестарых, но юзанных полных HP'шниках и микросерверах от них же...ммм. Потом правда очень долго бомбил - 2012 и 2012r2 встали на них без проблем, а хваленая "серверная" ОС - только с бубном и судорожным поиском дров.
Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

88. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Аноним (88), 22-Июн-21, 23:24 
Как будто НР выпускает сетевухи. Это был броадком какой-нибудь убогий. А у броадкомов прошивки убогие и потому надо было подбирать сервера внимательнее или докупать беспроблемное железо. Линукс тут ни при чем. Все претензии к блободелам.
Ответить | Правка | Наверх | Cообщить модератору

98. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Жироватт (ok), 23-Июн-21, 08:43 
Хм. А причем тут линукс, если ветка вся про бсд?
Ответить | Правка | Наверх | Cообщить модератору

116. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Аноним (88), 23-Июн-21, 11:18 
От перестановки блобов местами что-то меняется? Один хрен в блобе будет работать линукс.
Ответить | Правка | Наверх | Cообщить модератору

101. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  –1 +/
Сообщение от Жироватт (ok), 23-Июн-21, 08:46 
Ну перепутал, бывает.
Посыл все равно от этого не меняется: бздя может беспроблемно деплоиться в виртуалках на "стандартном" железе. Чуть что нестандартное - готовься или к е***не в пуском, или ограничениям generic-драйвера
Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

99. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  –1 +/
Сообщение от Брат Анон (ok), 23-Июн-21, 08:44 
Не покажете в каком месте у FreBSD написано, что их ОС сервер онли?
Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

147. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Michael Shigorinemail (ok), 23-Июн-21, 14:22 
Например, l_pcs.ko.

PS: понимаю, что Вы не в курсе.

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

7. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +3 +/
Сообщение от Шарп (ok), 22-Июн-21, 16:45 
Их там нет, потому что их никто не ищет. Неуловимый Джо.
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

9. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  –3 +/
Сообщение от макпыф (ok), 22-Июн-21, 16:51 
там все гораздо круче

https://www.opennet.dev/opennews/art.shtml?num=54843

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

16. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +1 +/
Сообщение от Аноним (16), 22-Июн-21, 17:09 
Как раз наоборот. Не видишь разницы? В FreeBSD не попал говнокод, если ты не понял после прочтения твоей же статьи.
Ответить | Правка | Наверх | Cообщить модератору

38. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  –1 +/
Сообщение от макпыф (ok), 22-Июн-21, 18:21 
> Как раз наоборот. Не видишь разницы? В FreeBSD не попал говнокод, если
> ты не понял после прочтения твоей же статьи.

как раз таки попал, (хотя и был удален до релиза) только разраб оригинального wireguard решил посмотреть что они там наваяли

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

39. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Аноним (39), 22-Июн-21, 18:26 
Ну, если сравнивать, то в линукс бекдоры попали в релизные ядра и были обнаружены не сразу.
Ответить | Правка | Наверх | Cообщить модератору

41. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  –5 +/
Сообщение от макпыф (ok), 22-Июн-21, 18:28 
> Ну, если сравнивать, то в линукс бекдоры попали в релизные ядра и
> были обнаружены не сразу.

ссылку даш на эти бекдоры в релизе?
bsd релизится редко, а ядро по неско раз в неделю, тут конечно времени чтобы найти до релиза проблемы у bsd больше

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

27. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +1 +/
Сообщение от Аноним (-), 22-Июн-21, 17:23 
> там все гораздо круче
> https://www.opennet.dev/opennews/art.shtml?num=54843

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

https://www.opennet.dev/opennews/art.shtml?num=55095
> 349 коммитов признаны корректными и оставлены без изменений. В 39 коммитах обнаружены проблемы, требующие исправления - данные коммиты отменены и до выпуска ядра 5.13 будут заменены на более корректные исправления. Ошибки в 25 коммитах оказались исправлены в последующих изменениях. 12 коммитов потеряли актуальность

Угу.


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

37. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  –2 +/
Сообщение от макпыф (ok), 22-Июн-21, 18:20 
>> там все гораздо круче
>> https://www.opennet.dev/opennews/art.shtml?num=54843
> Ну да, злоупотребивший доверием (и проср*вший все годы "работы на репутацию" -
> благодаря чему он почти и сумел пропихнуть этот код в ядро)
> разраб - это куда круче, чем
> https://www.opennet.dev/opennews/art.shtml?num=55095
>> 349 коммитов признаны корректными и оставлены без изменений. В 39 коммитах обнаружены проблемы, требующие исправления - данные коммиты отменены и до выпуска ядра 5.13 будут заменены на более корректные исправления. Ошибки в 25 коммитах оказались исправлены в последующих изменениях. 12 коммитов потеряли актуальность
> Угу.

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

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

72. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Аноним (-), 22-Июн-21, 20:41 

> это конечно хуже целого модуля являющегося откровенной халтурой. И в репозиторий он как раз попал (в релиз нет, это да)

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


>>> Разработчики ядра Linux завершили аудит всех патчей от Университета Миннесоты
> эммм, то что нашли 39 недочетов (не значит что значительных)

Ну да, ну да, 10% пропущенных "проблем" в патчах от "Васянов"  - "это другое!(с)"

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

18. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Онаним (?), 22-Июн-21, 17:11 
Почему вы до сих пор держите компьютер включенным в розетку?
Очевидно же, пока он не включен - уязвимости не могут быть эксплуатированы.
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

23. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +1 +/
Сообщение от Аноним (16), 22-Июн-21, 17:16 
Теоретически могут. Там ведь батарейка ещё есть.
Ответить | Правка | Наверх | Cообщить модератору

83. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  –2 +/
Сообщение от Онаним (?), 22-Июн-21, 22:36 
Теоретически батарейка там только часы держит. Даже DRAM подержать - её хватит на считанные минуты, а надо ещё как-то сеть инициализировать, которая внезапно вырвана вместе с питанием :D
Ответить | Правка | Наверх | Cообщить модератору

102. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Брат Анон (ok), 23-Июн-21, 08:49 
Теоретически батарейка позволяет по полной программе ноут ещё пару часов гонять.
Ответить | Правка | Наверх | Cообщить модератору

106. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Онаним (?), 23-Июн-21, 09:52 
Про ноут чуть ниже.
Ответить | Правка | Наверх | Cообщить модератору

84. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Онаним (?), 22-Июн-21, 22:38 
Если речь про ноут - то да, конечно же, вместе с розеткой надо батарейку извлекать.
Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

104. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Аноним (104), 23-Июн-21, 09:24 
Да-да. Выключил ноутбук из розетки, достал свою любимую отвертку под "торкс с дыркой" (или еще что там заботливо заложил производитель чтобы в ноутбук не лазили), перевернул ноут, выкрутил из зидней крышки штук двадцать маленьких шурупчиков, потом аккуратно прошелся по периметру задней крышки заботливо припасенным пластмассовым медиатором - расцепил все пластиковые защелки (не спеша, чтобы не поломать защелки) - и вуаля - вот он желанный разъем батарейки - осталось только аккуратно его пинцетом (где у нас тут пинцет, кстати) отцепить от материнки. :)
Ответить | Правка | Наверх | Cообщить модератору

105. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Онаним (?), 23-Июн-21, 09:52 
Китайский хлам (возможно даже от яббла) с неснимаемой батарейкой?
Ну, сочувствую, чего.
Ответить | Правка | Наверх | Cообщить модератору

107. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Онаним (?), 23-Июн-21, 09:58 
Для надёжности тогда стоит не просто в розетку не включать, но и дополнительно пройтись кувалдочкой.
Ответить | Правка | К родителю #104 | Наверх | Cообщить модератору

132. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Мимоходом... (?), 23-Июн-21, 12:38 
> пройтись кувалдочкой.

Недостаточно. Желательно ещё позвать знакомого сварщика и аргоном заполировать.
А если есть друг в хим.лаборатории, то и остатки сего серной кислотой побрызгать.

Иначе не будет достаточного уровня надёжности.

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

133. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Онаним (?), 23-Июн-21, 12:39 
Если носители только SSD - можно просто в микроволновке прожарить. Надёжно и быстро.
Ответить | Правка | Наверх | Cообщить модератору

138. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Мимоходом... (?), 23-Июн-21, 12:56 
Недостаточно. Остаётся соблазн отремонтировать ноут и грузиться с флешки.

Окрапление серной кислотой должно сопровождаться клятвенным обещанием себе самому не покупать новый  ноут, ПК, или смартфон на замену "обезвреженного". Только карандаш и бумага. Ну и курьер ещё иногда.

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

139. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Онаним (?), 23-Июн-21, 13:05 
После микроволновки ремонтировать там будет нечего :D
Ответить | Правка | Наверх | Cообщить модератору

33. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +2 +/
Сообщение от BorichL (ok), 22-Июн-21, 17:43 
Задранная вверх гузка не позволяет правильно мыслить.
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

58. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  –2 +/
Сообщение от Аноним (44), 22-Июн-21, 19:08 
Трезубец, торчащий из опы, лучше, да.
Ответить | Правка | Наверх | Cообщить модератору

161. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Аноним (161), 23-Июн-21, 15:08 
Ловите украинца!
Ответить | Правка | Наверх | Cообщить модератору

40. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +2 +/
Сообщение от Аноним (44), 22-Июн-21, 18:26 
>BSD? Очевидно же, что там таких уязвимостей нет.

Или их не искали?

PS Что-то подсказывает, что они определяются спекулятивным выполнением на CPU, независимо от ОС.

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

3. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  –2 +/
Сообщение от Аноним (3), 22-Июн-21, 16:34 
>Проблема проявляется начиная с выпуска ядра 4.15 и устранена в форме патчей (1, 2, 3, 4). В дистрибутивах уязвимость пока остаётся неисправленной (Debian, RHEL, Ubuntu, Fedora, SUSE, Arch).

Чё пацаны, самосбор и LFS?


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

4. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  –2 +/
Сообщение от Урри (ok), 22-Июн-21, 16:44 
и еще -10% к производительности.
Ответить | Правка | Наверх | Cообщить модератору

45. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +1 +/
Сообщение от Аноним (44), 22-Июн-21, 18:41 
Проблема в eBPF, можно собрать только ядро.
Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

69. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Аноним (69), 22-Июн-21, 20:16 
> Проблема в eBPF, можно собрать только ядро.

Он разве отключается? С 5 какой-то версии он не отключается. Вроде бы.

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

93. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Аноним (93), 23-Июн-21, 07:07 
Пересобрать с этими патчами.
Ответить | Правка | Наверх | Cообщить модератору

5. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +6 +/
Сообщение от Шарп (ok), 22-Июн-21, 16:44 
>еBPF

Уникальное шерето с JIT компиляцией. Очень по хипстерски. Такого в ядре ещё не было.

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

8. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +1 +/
Сообщение от Аноним (8), 22-Июн-21, 16:51 
Погодь, скоро раста дободяжат
Ответить | Правка | Наверх | Cообщить модератору

63. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Аноним (44), 22-Июн-21, 19:30 
Rust как-то способен избавить JIT-компиляторы, чтобы те не выдавали уязвимых к утечкам данных последовательностей команд?
Ответить | Правка | Наверх | Cообщить модератору

73. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Аноним (8), 22-Июн-21, 21:03 
Нет естественно
Просто в ядре станет больше того самого
И понизится порог входа в писатели ядра
Ответить | Правка | Наверх | Cообщить модератору

77. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Аноним (77), 22-Июн-21, 21:31 
Вы хотели сказать повысится
Ответить | Правка | Наверх | Cообщить модератору

79. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  –1 +/
Сообщение от Аноним (69), 22-Июн-21, 21:41 
На жс писать проще чем на ассемблере, при этом ассемблер проще. Тут то же самое.
Ответить | Правка | Наверх | Cообщить модератору

117. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от anonymous (??), 23-Июн-21, 11:23 
На rust писать сложнее, чем на Си.
Ответить | Правка | К родителю #73 | Наверх | Cообщить модератору

36. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  –4 +/
Сообщение от Ordu (ok), 22-Июн-21, 17:58 
Да, лучше когда несколько десятков (сотен?) фильтров файрвола написаны на C и выполняются непосредственно в ядерном адресном пространстве. Несомненно, это будет безопаснее. И конечно же быстрее, особенно когда вместо одного jit-фильтра у нас будет несколько C'шных цепочкой. Только хипстеру, ведь, может придти в голову, что прослойка виртуальной машины между всеми этими фильтрами и ядром может быть полезной.
Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

49. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Аноним (44), 22-Июн-21, 18:52 
Админам датацентров, которые, всё же, не C-программисты, недопускающие выход за границы массивов и обращений к невыделенной/освобождённой памяти, как-то проще писать на сильно ограниченном диалекте C, чем на натуральной Сишке. Да ещё, при этом, писать модули ядра.
Ответить | Правка | Наверх | Cообщить модератору

56. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  –2 +/
Сообщение от Ordu (ok), 22-Июн-21, 19:05 
> Админам датацентров, которые, всё же, не C-программисты, недопускающие выход за границы
> массивов и обращений к невыделенной/освобождённой памяти, как-то проще писать на сильно
> ограниченном диалекте C, чем на натуральной Сишке. Да ещё, при этом,
> писать модули ядра.

Админам датацентров, которые, всё же, не программисты, как-то проще иметь специализированный язык декларативного толка под такие задачи. Им C нахрен не нужен. Им бы что-нибудь, скажем, позволяющее описать классификацию трафика, а потом к каждому классу написать правило, что делать. Собственно у них так и было всегда -- всякие там iptables, nftables именно тем и занимаются, что предоставляют декларативный язык.

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

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

135. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  –4 +/
Сообщение от Онаним (?), 23-Июн-21, 12:41 
Ты не поверишь, "декларативные язычки" нужны в основном хипстерам от девляпсов, которые ни толком админы, ни толком программисты.
Ответить | Правка | Наверх | Cообщить модератору

143. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +1 +/
Сообщение от Ordu (ok), 23-Июн-21, 14:11 
> Ты не поверишь, "декларативные язычки" нужны в основном хипстерам от девляпсов, которые
> ни толком админы, ни толком программисты.

В смысле? Хмурые админы из 90-х не пользуются iptables?

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

173. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Онаним (?), 23-Июн-21, 20:28 
И давно iptables декларативны?
Ответить | Правка | Наверх | Cообщить модератору

174. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Ordu (ok), 23-Июн-21, 21:18 
> И давно iptables декларативны?

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

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

176. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Онаним (?), 24-Июн-21, 08:55 
Как раз таки императивны - ты детально описываешь каждое действие над проходящим трафиком, и детально описываешь, каким именно.

Из "декларативного типа" там разве что MASQUERADE, который сам догадывается, какой адрес подставить.

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

178. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Ordu (ok), 24-Июн-21, 10:51 
> Как раз таки императивны - ты детально описываешь каждое действие над проходящим
> трафиком, и детально описываешь, каким именно.
> Из "декларативного типа" там разве что MASQUERADE, который сам догадывается, какой адрес
> подставить.

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

Тут всё не так просто, потому что в некотором смысле, все эти последовательные запуски iptables -- это шелл-скрипт, который императивен. Он выполняется шаг за шагом, выполнили один шаг, сохранили результат, выполнили следующий шаг. Если последовательность выполнения шагов надо нарушить, скажем, хочется условного выполнения или многократного выполнения, то начинаются ветвления, циклы, goto, или ещё что-то _явно_ описанное. Последовательность выполнения, control-flow прописаны в коде => это императивщина. Если нет, если "программа" больше похожа на описание данных, или если она скорее описывает то, что хочется получить в результате выполнения программы, а не то как получить эти результаты, то это декларативщина.

Но такой шеллскрипт не разбирает пакетов, он собирает цепочки фильтров. Чувствуешь разницу? Не шелл-скрипт работает файрволлом, а netfilter в ядре, шелл-скрипт лишь конфигурирует netfilter. А конфигурация, практически всегда -- это декларативный код. Я видел исключения, скажем в dosemu были конфиги, написанные на императивном языке программирования. Реально, с if'ами, ветвлениями, циклами и тп. Но это редкое исключение.

> Из "декларативного типа" там разве что MASQUERADE, который сам догадывается, какой адрес подставить.

Не, это тоже декларативщина. Это же не control-flow, это не описание того _как_ надо преобразовать пакет, какое глобальное состояние для этого надо хранить и как его использовать -- нет. Это заявление, которое на русский можно было бы перевести фразой "и чтобы NAT был". Это описание желаемого результата, а не рецепт достижения такого результата.

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

179. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Онаним (?), 24-Июн-21, 12:38 
Цепочки фильтров - таки императивные примитивы, они проходятся всё так же последовательно, как собраны, без опоры на цели и сущности, в этом плане ничем не отличаясь от шел-скрипта, только для каждого пакета. Поэтому таки императив. С подпорками в виде conntrack и прочего, но это просто разные уровни абстракции.
Ответить | Правка | Наверх | Cообщить модератору

184. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Ordu (ok), 24-Июн-21, 21:19 
Отличительная черта императивщины, от декларативщины ведь в наличии control-flow, iptables позволяет настраивать data-flow.

Скажем такие штуки, как:

Window::new()
    .title("My Window")
    .width(800)
    .height(600)
...

считаются функциональщиной, так же как, я не знаю:

let result = my_array.iter()
    .filter(|x| x < 42)
    .map(|x| x*x)
    .collect();

В императивном стиле то же самое будет выглядеть как:

let mut result = Vec::new();
for x in my_array {
    if x < 42 {
        result.push(x*x)
    }
}

Во втором случае явно описывается control-flow, в первом описывается data-flow. А в первом случае, это ведь почти цепочка фильтров-преобразований как в iptables.

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

185. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Онаним (?), 24-Июн-21, 22:41 
То, да не то.
Многие -j являются заодно эквивалентом return, после чего flow прерывается, в этом очень существенное отличие от декларативного варианта.
Сложные вещи строятся на gosub'ах, но они являются частью императивного flow, не образуя законченных цепочек исполнения, и могут вывалиться в return на любом этапе.
И т.д. и т.п.

Я бы сравнил цепочки iptables с

function some_chain(packet)
{
  if (condition1) some_cool_action_1;
  if (condition2) { packet.action = J_ACCEPT; return true; }
  if (condition3) { packet.action = J_REJECT; return true; }
  if (condition4) { if (some_subchain(packet)) return true; }
  ...
  return false;
}

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

186. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Ordu (ok), 24-Июн-21, 23:04 
> Я бы сравнил цепочки iptables с
> function some_chain(packet)
> {
>   if (condition1) some_cool_action_1;
>   if (condition2) { packet.action = J_ACCEPT; return true; }
>   if (condition3) { packet.action = J_REJECT; return true; }
>   if (condition4) { if (some_subchain(packet)) return true; }
>   ...
>   return false;
> }

Ну это и есть декларативное программирование. То что оно в C оно синтаксически не отличается -- это лишь ограничения C'шного синтаксиса. Хотя, с другой стороны, даже в C ты не будешь так делать, потому что написанное не позволяет тебе собирать цепочки в рантайме. Ты будешь делать примерно так:

struct Rule {
    bool (*condition)(struct Packet *p, struct Environment *e);
    enum ActionReturns (*action)(struct Packet *p, struct Environment *e);
};

Потом ты напишешь что-то типа:

void netfiler_do_chain(struct Rule chain[], size_t n, struct Packet *p) {
    struct Environment e = make_environment();
    for(i = 0; i < n; i ++) {
        switch(chain[i].condition(p, &e)) {
            case STOP_PROCESSING: return true;
            ...
        }
    }
}

А потом ты будешь писать цепочки _декларациями_:

struct Rule my_chain[] = {
    { .condition = condition1, action = some_cool_action_1, },
    { .condition = ...},
    ...
}

> ни являются частью императивного flow, не образуя законченных цепочек исполнения, и могут вывалиться в return на любом этапе.

Это значит, что декларативность не pure декларативность. Но pure-декларативность бывает только в совсем-совсем уж конфигах, в тех, которые сводятся к перечислению имя=значение. В любом реалистичном случае, появляются отклонения. Это как со всеми этими няшными парадигмами. Тот же Prolog, при всей его декларативности, тоже от декларативности отклоняется. Pure декларативность может быть лишь тогда, когда задача реально разобрана, сильно продумана, и эта продуманность покрывает все use-case'ы. На практике, как правило, со временем вылезают usecase'ы, которые не были обдуманы заранее, и тут начинается костылестроение.

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

187. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Онаним (?), 24-Июн-21, 23:18 
Отличный пример перехода от синтаксиса iptables к синтаксису nft получился :D

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

Участие conntrack например явно декларативно, "мы тут NAT сделали, а теперь паши, родимый".

Для декларативности же правил конкретно не хватает того, что я уже написал в примере tcpdump vs iptables, в iptables нам приходится конкретику описывать. Вида "если до роутинга (PREROUTING) пришло на порт UDP 1234 (-p udp -m udp --dport 1234) нас самих, заменить назначение на 1.2.3.4 (-j DNAT --to 1.2.3.4)", и ещё с дополнением - "пропуская трафик (FORWARD), разрешить пакеты отовсюду в сторону 1.2.3.4:1234 (-d 1.2.3.4 -p udp -m udp --dport 1234)", которое обязано учитывать поменявшуюся в первом императиве ситуацию.

Чисто декларативным аналогом правил выше является например функция "проброс портов" в интерфейсах роутеров: "пробросить порт 1234 на сервер 1.2.3.4" - там есть это самое "как-нибудь", которое декларативный интерфейс разбирает в императив того же iptables.

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

181. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Онаним (?), 24-Июн-21, 15:59 
Ну вот MASQUERADE как раз и "не рецепт". Точнее, на половину "не рецепт".
А SNAT и DNAT - вполне себе "рецепты".
ACCEPT, REJECT - 100% рецепты.
И много чего прочего.
Ну и матчи - абсолютные рецепты по пакету, просто оформленные человеческим языком - в любом случае тебе к порту придётся протокол указывать :D Да ещё и какой модуль вгрузить.
Ответить | Правка | К родителю #178 | Наверх | Cообщить модератору

182. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Онаним (?), 24-Июн-21, 16:00 
Чисто для сравнения.

tcpdump тебе на port 1234 отдаст и tcp и udp и чёрта лысого
Вот это - декларативщина. Где он сам разберётся, где у него порт.
А в iptables тебе надо -p tcp или -p udp эксплицитно, да ещё и -m tcp / -m udp загрузить, чтобы --dport сработал. А если диапазон, то уже multiport отдельным указанием.

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

177. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Онаним (?), 24-Июн-21, 09:20 
Тот же nft отталкивается от сущностей, описывающих требуемые действия и элементы - он декларативен, да, но в силу этого хреново трассируем. Хотя в целом в меру.

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

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

136. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Онаним (?), 23-Июн-21, 12:42 
(как только декларация "сделай мне зашибись и смузи" работать перестаёт - те теряются)
Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

46. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Аноним (44), 22-Июн-21, 18:44 
Не было бы спекулятива, это не было бы уязвимостью. На Cortex-A53 эта уязвимость не прокатит.
Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

10. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +2 +/
Сообщение от Аноним (10), 22-Июн-21, 16:52 
>>Верификатор

eBPF настолько концептуально безопасная система, что ей понадобился встроенный антивирус?

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

25. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +1 +/
Сообщение от Онаним (?), 22-Июн-21, 17:17 
Ну JIT же.
Концептуально безопасный именно настолько.
Ответить | Правка | Наверх | Cообщить модератору

11. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  –14 +/
Сообщение от пох. (?), 22-Июн-21, 16:53 
Кто вообще обновляет это ядро? В андроид по 5-7 лет стоит обрубок и ничего. Никому не нужен этот ваш линукс.
Ответить | Правка | Наверх | Cообщить модератору

14. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +1 +/
Сообщение от Аноним (8), 22-Июн-21, 16:59 
Сервер этого сайта (да, где ты гадишь в комментах) на чем работает?
Ответить | Правка | Наверх | Cообщить модератору

17. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  –1 +/
Сообщение от Тинус Лорвальдс (ok), 22-Июн-21, 17:09 
Смею заметить, сервер этого сайта на опёнке, если меня не подводит склероз.
Ответить | Правка | Наверх | Cообщить модератору

24. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Аноним (16), 22-Июн-21, 17:17 
А ты вообще на федоре.
Ответить | Правка | Наверх | Cообщить модератору

65. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Тинус Лорвальдс (ok), 22-Июн-21, 19:31 
ути-пути. обиделся что ли?
Ответить | Правка | Наверх | Cообщить модератору

148. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Michael Shigorinemail (ok), 23-Июн-21, 14:34 
Передайте своему склерозу, что такое слышу вообще впервые.
Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

28. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +1 +/
Сообщение от Аноним (-), 22-Июн-21, 17:26 
> Сервер этого сайта (да, где ты гадишь в комментах) на чем работает?

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


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

42. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  –7 +/
Сообщение от пох. (?), 22-Июн-21, 18:34 
Мне нет дела до этого сервера, но его стоит ломануть хотя бы только из-за Шигорина
Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

48. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +4 +/
Сообщение от Аноним (48), 22-Июн-21, 18:50 
Если у вас что-то личное к шигорину, то может и лично его поцелуете?
Ответить | Правка | Наверх | Cообщить модератору

75. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +1 +/
Сообщение от нах.. (?), 22-Июн-21, 21:14 
Брежнев, залогинься.
Ответить | Правка | Наверх | Cообщить модератору

108. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +2 +/
Сообщение от n00by (ok), 23-Июн-21, 10:07 
Интересно, кого оригинальный обладатель ника так сильно зацепил, что тот принялся столь бездарно подставлять поха, попрошайничая о взломе сервера?
Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

123. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  –1 +/
Сообщение от данунах. (?), 23-Июн-21, 11:31 
Почему бездарно? Нормально
Ответить | Правка | Наверх | Cообщить модератору

157. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Аноним (-), 23-Июн-21, 14:52 
> Интересно, кого оригинальный обладатель ника так сильно зацепил, что тот принялся столь
> бездарно подставлять поха, попрошайничая о взломе сервера?

Точка на конце ника "немного намекает", что это - еще не оригинал:
https://www.opennet.dev/~%D0%CF%C8
https://www.opennet.dev/~%CE%C1%C8

Бездарные современные опеннетные lапчатые, у которых бомбануло, но возразить по существу оказалось нечего, остались только детсадовские приемчики.

У мну - точно так же многолетний акк "залочили", из под следующего (и похожих) - откровенные глупости писать стали ... тфу.

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

165. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от n00by (ok), 23-Июн-21, 15:30 
Я их не по лишним точкам различаю.)) Вот тут похож на оригинального https://www.opennet.dev/openforum/vsluhforumID3/124593.html#114
хоть и мало написал.
Ответить | Правка | Наверх | Cообщить модератору

29. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +1 +/
Сообщение от Анто Нимно (?), 22-Июн-21, 17:30 
> Кто вообще обновляет это ядро? В андроид по 5-7 лет стоит обрубок и ничего. Никому не нужен этот ваш линукс.

И дыры размера с тоннель для бронепоезда.

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

43. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  –2 +/
Сообщение от пох. (?), 22-Июн-21, 18:35 
> И дыры размера с тоннель для бронепоезда.

Я ж говорю, никому не нужен этот ваш линукс

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

50. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +3 +/
Сообщение от Аноним (44), 22-Июн-21, 18:55 
>В андроид по 5-7 лет стоит обрубок и ничего. Никому не нужен этот ваш линукс.

У тебя древняя Нокия, у меня кнопочник. Так да, можно рассуждать про ненужность Линукса на телефоне.

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

64. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  –7 +/
Сообщение от пох. (?), 22-Июн-21, 19:30 
То что ядро совсем не подходит для мобильной платформы, непонятно только самым упёртым
Ответить | Правка | Наверх | Cообщить модератору

67. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Аноним (69), 22-Июн-21, 19:52 
Ну и где QNX, который подходит? А может дело всё же в софте и удобстве разработки? Запускать любой обычный софт на телефоне вполне полезно. Вот что не подходит, так это жава -- батарейки то не резиновые.
Ответить | Правка | Наверх | Cообщить модератору

103. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  –1 +/
Сообщение от Совершенно другой аноним (?), 23-Июн-21, 08:50 
QNX6 поддерживал и нативную разработку (был и компилятор gcc, и своя среда разработки, построенная на Eclipse), и ARM-овские процессоры (правда не помню, было-ли это одновременно), но был сильно платный, как для разработчиков, так и в использовании (необходимо отчислять за каждое проданное устройство). А так, архитектурно, был очень неплохой.
Ответить | Правка | Наверх | Cообщить модератору

149. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +1 +/
Сообщение от Michael Shigorinemail (ok), 23-Июн-21, 14:35 
QNX тем более не подходит.
Ответить | Правка | К родителю #67 | Наверх | Cообщить модератору

155. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  –1 +/
Сообщение от Аноним (69), 23-Июн-21, 14:44 
> QNX тем более не подходит.

Почему же? Блэкбери сдох только сиараниями гугла, симбиан он вполне затыкал.

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

13. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +7 +/
Сообщение от Kuromi (ok), 22-Июн-21, 16:59 
"Автор оптимизации решил проверить, насколько изменится производительность после отключения защиты от Spectre. После загрузки системы с параметром "mitigations=off" время выполнения "rr sources" без оптимизации составило 2 минуты 5 секунд (в 1.6 раза быстрее), а с оптимизацией - 33 секунды (на 9% быстрее). Интересно, что отключение защиты от Spectre не только в 1.4 раза сократило время выполнения кода на уровне ядра (c 2m9s до 1m32s), но и в два раза уменьшило время выполнения в пространстве пользователя (c 1m9s до 0m33s), предположительно из-за снижения эффективности работы кэша CPU и сбросов TLB при включённой защите от Spectre."

Всего пара процентов, говорили они...

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

19. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  –1 +/
Сообщение от . (?), 22-Июн-21, 17:13 
И это афтар еще не пробовал сравнить ведро, где защиты нет в принципе от ведра с "mutigations=off" (ведь очень нужно и полезно в самом-самом time-critical месте ядра проверять миллион этих идиотских флажков - впрочем, там еще и архитектурно все изуродовано).

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

150. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Michael Shigorinemail (ok), 23-Июн-21, 14:35 
mutilations?
Ответить | Правка | Наверх | Cообщить модератору

21. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +2 +/
Сообщение от Аноним (88), 22-Июн-21, 17:14 
Не забываем про ноутбуки и не самые новые компы. Там наверное от отсутствия нормальной кеша страдания будут посерьезнее. Вместо того чтобы исправить уязвимости их пока заткнули. Потому что вместо работы кеша происходит отрубание оного, что как бы не может быть хорошим решением в конвеерной инфраструктуре. Создаваемые процы были рассчитаны только на работу с кешем, а не с кривой реализацией.
Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

22. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Аноним (88), 22-Июн-21, 17:15 
*нормальной работы
Ответить | Правка | Наверх | Cообщить модератору

160. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Аноним (161), 23-Июн-21, 15:02 
Он на Skylake (дырявое недоразумение) тестировал, на современных процах падение производительности минимально.
Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

34. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +1 +/
Сообщение от Ананоним (?), 22-Июн-21, 17:46 
Какая гадость эти ваши новые версии ядер.
Ответить | Правка | Наверх | Cообщить модератору

47. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +4 +/
Сообщение от Аноним (47), 22-Июн-21, 18:45 
А ведь проблема хардверная..
Ответить | Правка | Наверх | Cообщить модератору

51. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  –1 +/
Сообщение от Онаним (?), 22-Июн-21, 18:56 
Проблема в ДНК.
Напихать в ведро ЖИТов, позволяющих напрямую исполнять левый код, а потом удивляться, ой, ачо в них дыры-то.
Ответить | Правка | Наверх | Cообщить модератору

54. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Аноним (44), 22-Июн-21, 19:03 
А зачем позволять не руту загружать BPF-код? Может, обычным пользователям позволить и модули ядра грузить?
Ответить | Правка | Наверх | Cообщить модератору

57. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  –6 +/
Сообщение от Аноним (69), 22-Июн-21, 19:07 
Вообще-то хотелось бы уже нормальный фврйвол в линуксе увидеть, в венде ещё 20 лет назад фаревол лучше был (а может и до того), и это только штатный -- сторонние были ещё мощнее.
Ответить | Правка | Наверх | Cообщить модератору

60. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Аноним (44), 22-Июн-21, 19:14 
А вы видели, какие правила генерит GUI-морда этого лучше-файервола? Оно потом действительно так делает, как вы задумали? И я не видел. Правила iptables хоть видно.
Ответить | Правка | Наверх | Cообщить модератору

62. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  –1 +/
Сообщение от Аноним (69), 22-Июн-21, 19:24 
Ну я любитель tinywall и да там всё работает как должно, просто штатный интерфейс не слишком удобный.
Ответить | Правка | Наверх | Cообщить модератору

91. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +1 +/
Сообщение от СеменСеменыч777 (?), 23-Июн-21, 03:29 
> я любитель tinywall

https://tinywall.pados.hu/faq.php
"For completely other reasons though, it is recommended you leave Windows Firewall enabled." - чо ???

лучше бы ты был любителем ком.строки, там где-то есть .exe для управления встроенным фаером. или netsh или ipsecpol как-то так.

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

109. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от n00by (ok), 23-Июн-21, 10:16 
> в венде ещё 20 лет назад фаревол лучше был

Для тех, кто не успел родиться: 20 лет назад "Венды" то и не было. 98 и Millenium это такая надстройка над MS DOS.

Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору
Часть нити удалена модератором

112. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +1 +/
Сообщение от n00by (ok), 23-Июн-21, 10:32 
Лучше я подожду фантастический рассказ на тему, где Аноним это использовал.
Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

151. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Michael Shigorinemail (ok), 23-Июн-21, 14:36 
"I told all of my friends how they were losers for running UNIX. They
should switch to NT.... That was more or less my constant refrain until
a single pivotal event changed my life: I actually tried to use NT.
        -- Philip Greenspun

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

172. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от n00by (ok), 23-Июн-21, 20:18 
Вот где не лузеры http://www.online-solutions.ru/products/osss-security-suite....
Но Микрософт решила, что там файрволл слишком много даёт пользователю, да ещё и обновления может определить как вредоносную активность. Потому 10-ки нет в списке. Лет пять работы коту под хвост.
Ответить | Правка | Наверх | Cообщить модератору

119. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +1 +/
Сообщение от n00by (ok), 23-Июн-21, 11:25 
Туго с фантазией? Лан, не напрягайся. Докопирую за тебя со страницы, где ты расширил свой кругозор:

MS09-048: "The architecture to properly support TCP/IP protection does not exist on Microsoft Windows 2000 systems, making it infeasible to build the fix for Microsoft Windows 2000 Service Pack 4 to eliminate the vulnerability. [...]"

When Windows XP was originally shipped in October 2001, it included a limited firewall called "Internet Connection Firewall".

Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору
Часть нити удалена модератором

124. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +1 +/
Сообщение от n00by (ok), 23-Июн-21, 11:33 
Ты хочешь сказать, что бессмыслено тебя учить, что за слова следует отвечать? Так я не тебя учу. Ты лишь служишь примером.
Ответить | Правка | К родителю #151 | Наверх | Cообщить модератору
Часть нити удалена модератором

127. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +1 +/
Сообщение от n00by (ok), 23-Июн-21, 12:14 
Если бы твоё мышление не было бы столь фрагментарно, если бы ты мог не терять контекст и помнить свои сообщения на 1-2 назад, то ты бы знал, что заявил ты буквально следующее:

"20 лет назад фаревол лучше был". https://www.opennet.dev/openforum/vsluhforumID3/124593.html#57

В доказательство чему ты привёл дату выхода Windows 2000 "General availability February 17, 2000"
которая не имеет отношения к твоему заявлению.

Теперь ты пытаешься сплести _обрывки_ фактов, которые я заботливо тебе предоставил, что бы ты написал "судя по приведённому фрагменту". Действительно, по чему ты ещё можешь судить? Ты XP без SP в глаза не видел и не знаешь, что дата выхода и дата начала массового использования это две большие разницы. Это мы даже не учитываем, что из себе представляла функциональность тогдашнего Internet Connection Firewall, который тебе хватило ума приравнять к современенному.

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

131. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от n00by (ok), 23-Июн-21, 12:32 
Да, для тебя вообще без разницы и не имеют ровно никакого значения, что ты тут пишешь. У тебя был шанс дать ссылку сразу на XP. Если бы ты был хоть немного в теме, ты бы им воспользовался.
Ответить | Правка | К родителю #185 | Наверх | Cообщить модератору

140. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от n00by (ok), 23-Июн-21, 13:09 
> А ты не любишь признавать свою неправоту, да?

Я легко признаю, что я ошибся и ты не балабол, когда ты сможешь доказать своё исходное утверждение.

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

146. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +1 +/
Сообщение от n00by (ok), 23-Июн-21, 14:14 
>> Я легко признаю, что я ошибся и ты не балабол, когда ты
>> сможешь доказать своё исходное утверждение.
> Только после того, как ты докажешь своё.

Для неуспевших родиться: этот приём демагогии называется "переложить бремя доказательства на оппонента".

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

153. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Аноним (69), 23-Июн-21, 14:40 
Так ведь, ты сказал, буквально, что в 2001 никаких nt не было, и были только дос и надстройки. На что я заметил, что 2000 уже определённо была (и была она даже до me которую никто в своём уме не использовал), а xp там была позже и я вообще уверен был что ближе к 2003, а не в 2001, что уже никак не тянет на 20 лет (хотя проблема и не в этом). Насчёт висты, впрочем, я был уверен, что в 2006, а она в 2007 (когда я её видел уже повсеместно, как это возможно, если она только появилась в продаже? что-то подсказывает мне, что это дата, когда она уже установлена на всех оем устройствах в мире).

Про файерволы разговор отдельный, я прекрасно в курсе какая дрянь была 2000 и что до кучи патчей и обновлений она была не слишком юзабельна (а вот xp вполне себе по меркам того времени).

Возраст это для тебя очевидно болезненная тема, так что мой "совет" про "повзрослеть" тут пришёлся к месту.

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

158. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от n00by (ok), 23-Июн-21, 14:58 
> Так ведь, ты сказал, буквально, что в 2001 никаких nt не было

Вот опять ведь обманываешь. Буквально -- "Венды". NT так и называли -- NT. Я даже знал тогда аж целых двух админов, кто её админит.

Впрочем, мы отвелелись. Тебе следует доказывать наличие файерволла, а не вопрошать "а нас за шо?"

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

162. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Аноним (69), 23-Июн-21, 15:09 
Ты издеваешься? "Буквально" означает "в переносном смысле", у тебя как вообще с русским языком, нормально?

Далее. В икспи его не было? Икспи была 20 лет назад, но я видел только сп1 (что уже 2002 или 2003, что впрочем разница в 5-10%). Как тут верно заметили в соседней ветке, до висты что ли, файрвол был достаточно теоретический, однако и он был и он был на голову лучше того, что имеет линукс сегодня (с пользовательской точки зрения).

Динамический файрвол всегда лучше и удобнее статического, но дело не только в этом.

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

163. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от n00by (ok), 23-Июн-21, 15:23 
> "Буквально" означает "в переносном смысле"

1. нареч. к буквальный; точно соответствуя чему-либо, дословно
2. перен., разг. в знач. частицы действительно, на самом деле, прямо-таки
3. перен. в прямом смысле слова

https://ru.wiktionary.org/wiki/буквально

> Ты издеваешься?

Да, ты это заслужил.

> Далее. В икспи его не было?

Доказательство твоего утверждения -- это твоя головная боль.

> до висты что ли, файрвол был достаточно теоретический

Ой, взял сам себя и опроверг. ;)

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

166. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Аноним (69), 23-Июн-21, 15:35 
Спасибо, что процитировал, теперь перечитай 2 пункт, по-слогам.

>ты это заслужил

Orly? Судя по тому, что ты и читать можешь только по-слогам, у меня есть определённые вопросы.

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

168. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от n00by (ok), 23-Июн-21, 16:22 
> Спасибо, что процитировал, теперь перечитай 2 пункт, по-слогам.

Твоя просьба должна выглядеть так: "объясните, пожалуйста, смысл словарных сокращений".

2. перен., разг. в знач. частицы действительно, на самом деле, прямо-таки

Переносными значениями в разговорной речи, когда слово "буквально" употребляется в значении частицы, являются: "действительно", "на самом деле", "прямо-таки".

> Orly? Судя по тому, что ты и читать можешь только по-слогам, у
> меня есть определённые вопросы.

Извини, я не знаю, почему ты такой глупый.

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

170. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Аноним (69), 23-Июн-21, 16:28 
Ты только и делаешь, что агрессируешь, это уныло и ничуть не красит. Самое интересное, что считаешь себя правым, даже когда я объяснил свою позицию доходчивым образом и уже самое время осознать свои ошибки. Появилось ощущение, что гадишь в комментах ты не по фану, и это скорее какое-то расстройство. Я не специалист в этом вопросе и не могу судить.
Ответить | Правка | К родителю #168 | Наверх | Cообщить модератору

175. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от n00by (ok), 24-Июн-21, 07:22 
Реальность такова, что не обязана всем нравиться: https://youtu.be/97ghLVUhtUw
Ответить | Правка | К родителю #170 | Наверх | Cообщить модератору

152. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Michael Shigorinemail (ok), 23-Июн-21, 14:38 
> А всё дело в том, что 5 лет разницы не имеют ровно никакого значения.

Давайте-ка уберу Ваш выхлоп, который как раз и не имеет ни смысла, ни значения.  Благодарить можете сразу в спортлото, вот так же повиливая.

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

154. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Аноним (69), 23-Июн-21, 14:41 
Ну-ну, ты в своём репертуаре.
Ответить | Правка | К родителю #152 | Наверх | Cообщить модератору

180. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от СеменСеменыч777 (?), 24-Июн-21, 14:25 
> Давайте-ка уберу Ваш выхлоп

очень зря. любители щелкать чекбоксы в гуе должны страдать.
теперь и не докажешь ничего.

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

128. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +1 +/
Сообщение от n00by (ok), 23-Июн-21, 12:19 
Да не, не торопись. Сначала дай ссылку, где написано про файрволл NT 3.1. ;)
Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

159. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +1 +/
Сообщение от Аноним (-), 23-Июн-21, 15:01 
> и это только штатный -- сторонние были ещё мощнее.

И элементарно обходились в юзерспейсе самого приложения (Tiny/Kerio), потому что "работали" через инъекцию DLL ...

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

92. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от СеменСеменыч777 (?), 23-Июн-21, 06:52 
не-рут становится рут через атаку локал рут.
а этих локал рутов в ядре на 100 лет вперед припасено.
Ответить | Правка | К родителю #54 | Наверх | Cообщить модератору

94. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Аноним (93), 23-Июн-21, 07:22 
Речь-то шла о законной возможности загрузить в ядро какой-то код. Но если эта возможность даётся только руту, то он, по определению, способен думать, что он туда вгружает.
Ответить | Правка | Наверх | Cообщить модератору

52. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +2 +/
Сообщение от Анонимemail (52), 22-Июн-21, 18:57 
давно такого не было и вот опять.Кстати как там с защитой в 11 поколении Интела дела обстоят?
Ответить | Правка | Наверх | Cообщить модератору

156. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Anonanus (?), 23-Июн-21, 14:48 
lscpu вот это выдает
Vulnerability Itlb multihit:     Not affected
Vulnerability L1tf:              Not affected
Vulnerability Mds:               Not affected
Vulnerability Meltdown:          Not affected
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl and seccomp
Vulnerability Spectre v1:        Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2:        Mitigation; Enhanced IBRS, IBPB conditional, RSB filling
Vulnerability Srbds:             Not affected
Vulnerability Tsx async abort:   Not affected
Ответить | Правка | Наверх | Cообщить модератору

55. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +2 +/
Сообщение от псевдонимус (?), 22-Июн-21, 19:03 
Вот говорили аноны от любителей до профессионалов: не тащите вы в рот какашку...

Рукалицо &-(

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

59. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +2 +/
Сообщение от Аноним (8), 22-Июн-21, 19:12 
iptables и nftables имеют фатальный недостаток - написаны не ими
И, что ещё хуже, неугодны системде
Ответить | Правка | Наверх | Cообщить модератору

61. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +1 +/
Сообщение от Аноним (44), 22-Июн-21, 19:23 
Кстати, nftables тоже свой байткод генерит, который исполняется своей виртальной машиной в ядре.
Ответить | Правка | Наверх | Cообщить модератору

78. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  –1 +/
Сообщение от Аноним (77), 22-Июн-21, 21:34 
Многие тут даже не знают что и в SQLite используется виртуальная машина
Ответить | Правка | Наверх | Cообщить модератору

82. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +3 +/
Сообщение от Онаним (?), 22-Июн-21, 22:34 
И давно ли SQLite работает в пространстве ядра? :D
Ответить | Правка | Наверх | Cообщить модератору

96. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  –1 +/
Сообщение от ryoken (ok), 23-Июн-21, 08:23 
Погодите, и это притащат.
Ответить | Правка | Наверх | Cообщить модератору

70. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  –1 +/
Сообщение от псевдонимус (?), 22-Июн-21, 20:22 
> iptables и nftables имеют фатальный недостаток - написаны не ими
> И, что ещё хуже, неугодны системде

Вся эта мышиная возня делается с целью оптимизации, т.е. хотят сэкономить на персонале.

Но скупой платит дважды. Хапуги этого не понимают, никогда не могут вовремя остановиться.

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

118. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от anonymous (??), 23-Июн-21, 11:25 
BPF в ядре -- это вообще не про замену netfilter. Это невозможность отлаживать локальные приложения, скорее.
Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

120. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от anonymous (??), 23-Июн-21, 11:26 
автозамена. невозможность => про возможность
Ответить | Правка | Наверх | Cообщить модератору

74. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  –1 +/
Сообщение от нах.. (?), 22-Июн-21, 21:10 
А можжет это вендорское уг bpf выкинуть и все? Аааа ну да у хомяков мозг уже промыт.
Ответить | Правка | Наверх | Cообщить модератору

85. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  –1 +/
Сообщение от Онаним (?), 22-Июн-21, 22:41 
Доскеры ж не смогут свой костыль под файрвол тогда подкладывать, беда-печаль.
Ответить | Правка | Наверх | Cообщить модератору

113. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  –1 +/
Сообщение от нах.. (?), 23-Июн-21, 10:58 
> Доскеры ж не смогут свой костыль под файрвол тогда подкладывать, беда-печаль.

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


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

121. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +1 +/
Сообщение от anonymous (??), 23-Июн-21, 11:28 
BPF -- это не про netfilter. И Docker-у BPF для работы не нужен. BPF -- это скорее инструмент хорошего сисадмина, позволяющий отлаживать неотлаживаемое.
Ответить | Правка | К родителю #85 | Наверх | Cообщить модератору

86. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  –2 +/
Сообщение от пох. (?), 22-Июн-21, 23:04 
Какой уровень специалиста нужен, чтобы этим способом ломануть рабочую станцию? И что вообще он может выудить такого, о чём я должен беспокоиться?)
Ответить | Правка | Наверх | Cообщить модератору

90. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Аноним (90), 23-Июн-21, 00:52 
Как по мне, так рандомное чтение крошечных фрагментов памяти (пускай и занятых) это фигня - косяк конечно постыдный, но никто не пострадает.
Ответить | Правка | Наверх | Cообщить модератору

164. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Аноним (164), 23-Июн-21, 15:24 
В ютубе есть канал BlackHat, где есть демонстрации атак с попаданием/промахом в кэш. Это уязвимость другого сорта, но суть одна — прочитать память другого приложения (или библиотеки) непривилегированным кодом.
Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

89. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Songo (ok), 23-Июн-21, 00:29 
Надо ведь продавать новые компы, вот и выдумывают всякую ерунду для замедления, прям как в Огрызке, что не новая версия, так замедления "старых" устройств.
Ответить | Правка | Наверх | Cообщить модератору

95. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +2 +/
Сообщение от Аноним (93), 23-Июн-21, 07:28 
Так, может, лучше честно просто отказаться от спекулятива в процессорах? Тогда и костыли по замедлению не нужны будут.
Ответить | Правка | Наверх | Cообщить модератору

97. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  –1 +/
Сообщение от ryoken (ok), 23-Июн-21, 08:24 
Напомните, кто в курсе, на PPC64 это всё распространяется?
Ответить | Правка | Наверх | Cообщить модератору

111. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от n00by (ok), 23-Июн-21, 10:28 
Проверьте

# grep  '' /sys/devices/system/cpu/vulnerabilities/*
/sys/devices/system/cpu/vulnerabilities/itlb_multihit:Not affected
/sys/devices/system/cpu/vulnerabilities/l1tf:Not affected
/sys/devices/system/cpu/vulnerabilities/mds:Not affected
/sys/devices/system/cpu/vulnerabilities/meltdown:Not affected
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Not affected
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Not affected
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Not affected
/sys/devices/system/cpu/vulnerabilities/srbds:Not affected
/sys/devices/system/cpu/vulnerabilities/tsx_async_abort:Not affected

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

114. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  –2 +/
Сообщение от нах.. (?), 23-Июн-21, 10:59 
> # grep  '' /sys/devices/system/cpu/vulnerabilities/*
> /sys/devices/system/cpu/vulnerabilities/itlb_multihit:Not affected
> /sys/devices/system/cpu/vulnerabilities/l1tf:Not affected
> /sys/devices/system/cpu/vulnerabilities/mds:Not affected
> /sys/devices/system/cpu/vulnerabilities/meltdown:Not affected
> /sys/devices/system/cpu/vulnerabilities/spec_store_bypass:Not affected
> /sys/devices/system/cpu/vulnerabilities/spectre_v1:Not affected
> /sys/devices/system/cpu/vulnerabilities/spectre_v2:Not affected
> /sys/devices/system/cpu/vulnerabilities/srbds:Not affected
> /sys/devices/system/cpu/vulnerabilities/tsx_async_abort:Not affected

Главное - верить!

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

115. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от n00by (ok), 23-Июн-21, 11:17 
Раритета. ;)

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

167. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Аноним (44), 23-Июн-21, 15:38 
PPC 601?
Ответить | Правка | Наверх | Cообщить модератору

169. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от n00by (ok), 23-Июн-21, 16:24 
Ну не настолько. Atom N270.
Ответить | Правка | Наверх | Cообщить модератору

129. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  –2 +/
Сообщение от Ананоним (?), 23-Июн-21, 12:21 
Огромная куча кода разного качества, каким-то чудом работающая, в которую ежедневно-постоянно вносятся исправления с новыми ошибками, которая "протухает" в лучшем случае еженедельно, созданная по принципу "Х**к х**к и в продакшн". Да, это всё наш Linux. А всё от того, что программистам хочется кушать.
Ответить | Правка | Наверх | Cообщить модератору

141. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +1 +/
Сообщение от Мимоходом... (?), 23-Июн-21, 13:09 
Да, это всё наш Linux, MacOS/OSX, Android, Windows, и прочие BSD... извините, если кого забыл.

А так же микрокод Intel, AMD, Nvidia, ARM и ещё несколько... только не еженедельно а 3-6 месяцев.

Добро пожаловать в 21 век, где бабло окончательно побеждает зло и готовится победить здравый смысл.

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

145. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Ананоним (?), 23-Июн-21, 14:13 
Покажи мне здесь 3-6 месяцев:
https://github.com/archlinux/svntogit-packages/commits/packa...
Ответить | Правка | Наверх | Cообщить модератору

171. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Fractal cucumber (ok), 23-Июн-21, 20:06 
Сижу на 4.9, протухать и не думаю.
Ответить | Правка | К родителю #129 | Наверх | Cообщить модератору

188. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от Сейд (ok), 25-Июн-21, 01:22 
Пора переходить на RISC-V.
Ответить | Правка | Наверх | Cообщить модератору

189. "Уязвимости в подсистеме eBPF, позволяющие обойти защиту от а..."  +/
Сообщение от MATPOC (?), 25-Июн-21, 12:08 
curl https://make-linux-fast-again.com
Ответить | Правка | Наверх | Cообщить модератору

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

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




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

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