В ядре Linux выявлена уязвимость (CVE-2021-33624), позволяющая использовать подсистему еBPF для обхода защиты от уязвимостей класса Spectre, дающих возможность определить содержимое памяти в результате создания условий для спекулятивного выполнения определённых операций. Для атаки Spectre требуется наличие в привилегированном коде определённой последовательности команд, приводящих к спекулятивному выполнению инструкций. Через манипуляцию с передаваемыми для выполнения BPF-программами можно добиться генерации подобных инструкций в еBPF и добиться утечки по сторонним каналам содержимого памяти ядра и произвольных областей физической памяти...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=55371
Почему вы до сих пор не на BSD? Очевидно же, что там таких уязвимостей нет.
как и нормальной поддержки туевой хучи оборудования, к сожалению
огласите весь список что на сервер надо
а я по предположению анона выше должен с сервера эту новость читать?
Нет же. Сервер у вас в окошке Pytty будет, а новость в бжественной Десяточке читайте.
> Нет же. Сервер у вас в окошке Pytty будет,
> а новость в бжественной Десяточке читайте.
> бжественной ДесяточкеОчередной WSLщик-Петросян совсем не палится ...
https://i.postimg.cc/SxVZBVyD/2021-06-22-19-29.png
"И вот так - у вас все!"(с)
Как?
> Как?Так - по опеннетно-пингвинячьи. Т.е. натужно спетросянить про Путти, попутно нахваливая "бжественную десяточку" - и, как обычно, промахнуться своими фантазиями мимо реальности (или где там на скрине можно путти с десяточкой увидеть?)
> как обычно, промахнуться своими фантазиями мимо реальности
> (или где там на скрине можно путти с десяточкой увидеть?)Как на чужом компе это можно было разглядеть?))
На виртуальный сервер с неким набором "стандартного эмулируемого железа - без проблем.
Ставишь в качестве простого гипервизора на реальном серверном (сервернее некуда)железе - хренушки, сказали заюшки.
Ставишь её в виртуалку, но немного недефолтным железом - оппа, у нас тут рулеточка, что заведется сразу, что - с полупинка, а что - надо кормить линуксовыми дровами!
Хочешь превратить списанный дроволет в легких нетребовательный сервер? Ха! Рулетка еще более русская, запас секса обеспечен.
Ну может хотя бы на нетребовательную, стандартную роутеровскую досточку? Фигвам, называется, накатывается линуксячий openwrt.
Какие будут оправдания?
> Жироватт
> На виртуальный сервер с неким набором "стандартного эмулируемого железа - без проблем.
> Ставишь в качестве простого гипервизора на реальном серверном (сервернее некуда)железе
> - хренушки, сказали заюшки.
> Ставишь её в виртуалку, но немного недефолтным железом - оппа, у нас
> тут рулеточка, что заведется сразу, что - с полупинка, а что
> - надо кормить линуксовыми дровами!...
> Какие будут оправдания?Ты в нике использовал букву 'и' вместо положенного 'ы' - какие еще могут быть "оправдания"?
Ты второе и третье перепутал.
Как вспомню, как я любился с сетевухами и матерями на нестарых, но юзанных полных HP'шниках и микросерверах от них же...ммм. Потом правда очень долго бомбил - 2012 и 2012r2 встали на них без проблем, а хваленая "серверная" ОС - только с бубном и судорожным поиском дров.
Как будто НР выпускает сетевухи. Это был броадком какой-нибудь убогий. А у броадкомов прошивки убогие и потому надо было подбирать сервера внимательнее или докупать беспроблемное железо. Линукс тут ни при чем. Все претензии к блободелам.
Хм. А причем тут линукс, если ветка вся про бсд?
От перестановки блобов местами что-то меняется? Один хрен в блобе будет работать линукс.
Ну перепутал, бывает.
Посыл все равно от этого не меняется: бздя может беспроблемно деплоиться в виртуалках на "стандартном" железе. Чуть что нестандартное - готовься или к е***не в пуском, или ограничениям generic-драйвера
Не покажете в каком месте у FreBSD написано, что их ОС сервер онли?
Например, l_pcs.ko.PS: понимаю, что Вы не в курсе.
Их там нет, потому что их никто не ищет. Неуловимый Джо.
там все гораздо круче
Как раз наоборот. Не видишь разницы? В FreeBSD не попал говнокод, если ты не понял после прочтения твоей же статьи.
> Как раз наоборот. Не видишь разницы? В FreeBSD не попал говнокод, если
> ты не понял после прочтения твоей же статьи.как раз таки попал, (хотя и был удален до релиза) только разраб оригинального wireguard решил посмотреть что они там наваяли
Ну, если сравнивать, то в линукс бекдоры попали в релизные ядра и были обнаружены не сразу.
> Ну, если сравнивать, то в линукс бекдоры попали в релизные ядра и
> были обнаружены не сразу.ссылку даш на эти бекдоры в релизе?
bsd релизится редко, а ядро по неско раз в неделю, тут конечно времени чтобы найти до релиза проблемы у bsd больше
> там все гораздо круче
> https://www.opennet.dev/opennews/art.shtml?num=54843Ну да, злоупотребивший доверием (и проср*вший все годы "работы на репутацию" - благодаря чему он почти и сумел пропихнуть этот код в ядро) разраб - это куда круче, чем
https://www.opennet.dev/opennews/art.shtml?num=55095
> 349 коммитов признаны корректными и оставлены без изменений. В 39 коммитах обнаружены проблемы, требующие исправления - данные коммиты отменены и до выпуска ядра 5.13 будут заменены на более корректные исправления. Ошибки в 25 коммитах оказались исправлены в последующих изменениях. 12 коммитов потеряли актуальностьУгу.
>> там все гораздо круче
>> 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 недочетов (не значит что значительных) это конечно хуже целого модуля являющегося откровенной халтурой. И в репозиторий он как раз попал (в релиз нет, это да)
> это конечно хуже целого модуля являющегося откровенной халтурой. И в репозиторий он как раз попал (в релиз нет, это да)
Хорошо, что ты тоже это признаешь. Ведь сравнить халтуру в одном модуле (причем, обнаруженную) от злоупотребившего многолетней репутацией и доверием (и получившим после этого пинок под зад) с кучей патчей от левых чуваков, раскиданный по всему ядру - все равно что сравнить палец с жопой.
>>> Разработчики ядра Linux завершили аудит всех патчей от Университета Миннесоты
> эммм, то что нашли 39 недочетов (не значит что значительных)Ну да, ну да, 10% пропущенных "проблем" в патчах от "Васянов" - "это другое!(с)"
Почему вы до сих пор держите компьютер включенным в розетку?
Очевидно же, пока он не включен - уязвимости не могут быть эксплуатированы.
Теоретически могут. Там ведь батарейка ещё есть.
Теоретически батарейка там только часы держит. Даже DRAM подержать - её хватит на считанные минуты, а надо ещё как-то сеть инициализировать, которая внезапно вырвана вместе с питанием :D
Теоретически батарейка позволяет по полной программе ноут ещё пару часов гонять.
Про ноут чуть ниже.
Если речь про ноут - то да, конечно же, вместе с розеткой надо батарейку извлекать.
Да-да. Выключил ноутбук из розетки, достал свою любимую отвертку под "торкс с дыркой" (или еще что там заботливо заложил производитель чтобы в ноутбук не лазили), перевернул ноут, выкрутил из зидней крышки штук двадцать маленьких шурупчиков, потом аккуратно прошелся по периметру задней крышки заботливо припасенным пластмассовым медиатором - расцепил все пластиковые защелки (не спеша, чтобы не поломать защелки) - и вуаля - вот он желанный разъем батарейки - осталось только аккуратно его пинцетом (где у нас тут пинцет, кстати) отцепить от материнки. :)
Китайский хлам (возможно даже от яббла) с неснимаемой батарейкой?
Ну, сочувствую, чего.
Для надёжности тогда стоит не просто в розетку не включать, но и дополнительно пройтись кувалдочкой.
> пройтись кувалдочкой.Недостаточно. Желательно ещё позвать знакомого сварщика и аргоном заполировать.
А если есть друг в хим.лаборатории, то и остатки сего серной кислотой побрызгать.Иначе не будет достаточного уровня надёжности.
Если носители только SSD - можно просто в микроволновке прожарить. Надёжно и быстро.
Недостаточно. Остаётся соблазн отремонтировать ноут и грузиться с флешки.Окрапление серной кислотой должно сопровождаться клятвенным обещанием себе самому не покупать новый ноут, ПК, или смартфон на замену "обезвреженного". Только карандаш и бумага. Ну и курьер ещё иногда.
После микроволновки ремонтировать там будет нечего :D
Задранная вверх гузка не позволяет правильно мыслить.
Трезубец, торчащий из опы, лучше, да.
Ловите украинца!
>BSD? Очевидно же, что там таких уязвимостей нет.Или их не искали?
PS Что-то подсказывает, что они определяются спекулятивным выполнением на CPU, независимо от ОС.
>Проблема проявляется начиная с выпуска ядра 4.15 и устранена в форме патчей (1, 2, 3, 4). В дистрибутивах уязвимость пока остаётся неисправленной (Debian, RHEL, Ubuntu, Fedora, SUSE, Arch).Чё пацаны, самосбор и LFS?
и еще -10% к производительности.
Проблема в eBPF, можно собрать только ядро.
> Проблема в eBPF, можно собрать только ядро.Он разве отключается? С 5 какой-то версии он не отключается. Вроде бы.
Пересобрать с этими патчами.
>еBPFУникальное шерето с JIT компиляцией. Очень по хипстерски. Такого в ядре ещё не было.
Погодь, скоро раста дободяжат
Rust как-то способен избавить JIT-компиляторы, чтобы те не выдавали уязвимых к утечкам данных последовательностей команд?
Нет естественно
Просто в ядре станет больше того самого
И понизится порог входа в писатели ядра
Вы хотели сказать повысится
На жс писать проще чем на ассемблере, при этом ассемблер проще. Тут то же самое.
На rust писать сложнее, чем на Си.
Да, лучше когда несколько десятков (сотен?) фильтров файрвола написаны на C и выполняются непосредственно в ядерном адресном пространстве. Несомненно, это будет безопаснее. И конечно же быстрее, особенно когда вместо одного jit-фильтра у нас будет несколько C'шных цепочкой. Только хипстеру, ведь, может придти в голову, что прослойка виртуальной машины между всеми этими фильтрами и ядром может быть полезной.
Админам датацентров, которые, всё же, не C-программисты, недопускающие выход за границы массивов и обращений к невыделенной/освобождённой памяти, как-то проще писать на сильно ограниченном диалекте C, чем на натуральной Сишке. Да ещё, при этом, писать модули ядра.
> Админам датацентров, которые, всё же, не C-программисты, недопускающие выход за границы
> массивов и обращений к невыделенной/освобождённой памяти, как-то проще писать на сильно
> ограниченном диалекте C, чем на натуральной Сишке. Да ещё, при этом,
> писать модули ядра.Админам датацентров, которые, всё же, не программисты, как-то проще иметь специализированный язык декларативного толка под такие задачи. Им C нахрен не нужен. Им бы что-нибудь, скажем, позволяющее описать классификацию трафика, а потом к каждому классу написать правило, что делать. Собственно у них так и было всегда -- всякие там iptables, nftables именно тем и занимаются, что предоставляют декларативный язык.
Вот программистам датацентров, которые может быть и C-программисты (которые как и все C-программисты позволяют себе выходить за границы массивов и обращаться к невыделенной/освобождённой памяти), как раз очень удобно иметь песочницу на тот случай, если цепочки существующих фильтров оказываются слишком медленными, и встаёт вопрос написания фильтра заточенного под конкретную задачу, который будет классифицировать трафик быстрее.
Ты не поверишь, "декларативные язычки" нужны в основном хипстерам от девляпсов, которые ни толком админы, ни толком программисты.
> Ты не поверишь, "декларативные язычки" нужны в основном хипстерам от девляпсов, которые
> ни толком админы, ни толком программисты.В смысле? Хмурые админы из 90-х не пользуются iptables?
И давно iptables декларативны?
> И давно iptables декларативны?Всегда были. Ты декларируешь таблички, цепочки фильтров, и тд, и тп. Ты не описываешь императивно, то есть это не императивный язык. Функциональщиной это тоже не назвать, хотя функциональщина -- это разновидность декларативности. Это декларативность.
Как раз таки императивны - ты детально описываешь каждое действие над проходящим трафиком, и детально описываешь, каким именно.Из "декларативного типа" там разве что MASQUERADE, который сам догадывается, какой адрес подставить.
> Как раз таки императивны - ты детально описываешь каждое действие над проходящим
> трафиком, и детально описываешь, каким именно.
> Из "декларативного типа" там разве что MASQUERADE, который сам догадывается, какой адрес
> подставить.Не, там практически всё декларативно. В том, что ты пишешь при помощи iptables нет алгоритма разбора пакетов. Алгоритм выглядел бы в стиле "вынуть пакет из очереди, вот так вот поветвиться, сверившись с глобальным состоянием, и в конце каждой ветви что-то с пакетом сделать -- засунуть в другую очередь, скорее всего. И реализация такого алгоритма была бы императивной программой.
Тут всё не так просто, потому что в некотором смысле, все эти последовательные запуски iptables -- это шелл-скрипт, который императивен. Он выполняется шаг за шагом, выполнили один шаг, сохранили результат, выполнили следующий шаг. Если последовательность выполнения шагов надо нарушить, скажем, хочется условного выполнения или многократного выполнения, то начинаются ветвления, циклы, goto, или ещё что-то _явно_ описанное. Последовательность выполнения, control-flow прописаны в коде => это императивщина. Если нет, если "программа" больше похожа на описание данных, или если она скорее описывает то, что хочется получить в результате выполнения программы, а не то как получить эти результаты, то это декларативщина.
Но такой шеллскрипт не разбирает пакетов, он собирает цепочки фильтров. Чувствуешь разницу? Не шелл-скрипт работает файрволлом, а netfilter в ядре, шелл-скрипт лишь конфигурирует netfilter. А конфигурация, практически всегда -- это декларативный код. Я видел исключения, скажем в dosemu были конфиги, написанные на императивном языке программирования. Реально, с if'ами, ветвлениями, циклами и тп. Но это редкое исключение.
> Из "декларативного типа" там разве что MASQUERADE, который сам догадывается, какой адрес подставить.
Не, это тоже декларативщина. Это же не control-flow, это не описание того _как_ надо преобразовать пакет, какое глобальное состояние для этого надо хранить и как его использовать -- нет. Это заявление, которое на русский можно было бы перевести фразой "и чтобы NAT был". Это описание желаемого результата, а не рецепт достижения такого результата.
Цепочки фильтров - таки императивные примитивы, они проходятся всё так же последовательно, как собраны, без опоры на цели и сущности, в этом плане ничем не отличаясь от шел-скрипта, только для каждого пакета. Поэтому таки императив. С подпорками в виде conntrack и прочего, но это просто разные уровни абстракции.
Отличительная черта императивщины, от декларативщины ведь в наличии 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.
То, да не то.
Многие -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;
}
> Я бы сравнил цепочки 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'ы, которые не были обдуманы заранее, и тут начинается костылестроение.
Отличный пример перехода от синтаксиса 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.
Ну вот MASQUERADE как раз и "не рецепт". Точнее, на половину "не рецепт".
А SNAT и DNAT - вполне себе "рецепты".
ACCEPT, REJECT - 100% рецепты.
И много чего прочего.
Ну и матчи - абсолютные рецепты по пакету, просто оформленные человеческим языком - в любом случае тебе к порту придётся протокол указывать :D Да ещё и какой модуль вгрузить.
Чисто для сравнения.tcpdump тебе на port 1234 отдаст и tcp и udp и чёрта лысого
Вот это - декларативщина. Где он сам разберётся, где у него порт.
А в iptables тебе надо -p tcp или -p udp эксплицитно, да ещё и -m tcp / -m udp загрузить, чтобы --dport сработал. А если диапазон, то уже multiport отдельным указанием.
Тот же nft отталкивается от сущностей, описывающих требуемые действия и элементы - он декларативен, да, но в силу этого хреново трассируем. Хотя в целом в меру.А вот в iptables ты задаёшь полностью чёткую последовательность операций над единичными элементами, это явно не декларативность, там даже сущности толком не создать.
(как только декларация "сделай мне зашибись и смузи" работать перестаёт - те теряются)
Не было бы спекулятива, это не было бы уязвимостью. На Cortex-A53 эта уязвимость не прокатит.
>>ВерификаторeBPF настолько концептуально безопасная система, что ей понадобился встроенный антивирус?
Ну JIT же.
Концептуально безопасный именно настолько.
Кто вообще обновляет это ядро? В андроид по 5-7 лет стоит обрубок и ничего. Никому не нужен этот ваш линукс.
Сервер этого сайта (да, где ты гадишь в комментах) на чем работает?
Смею заметить, сервер этого сайта на опёнке, если меня не подводит склероз.
А ты вообще на федоре.
ути-пути. обиделся что ли?
Передайте своему склерозу, что такое слышу вообще впервые.
> Сервер этого сайта (да, где ты гадишь в комментах) на чем работает?Почти два десятка лет - ну вот совсем-совсем не на пингвинчике работал.
Мне нет дела до этого сервера, но его стоит ломануть хотя бы только из-за Шигорина
Если у вас что-то личное к шигорину, то может и лично его поцелуете?
Брежнев, залогинься.
Интересно, кого оригинальный обладатель ника так сильно зацепил, что тот принялся столь бездарно подставлять поха, попрошайничая о взломе сервера?
Почему бездарно? Нормально
> Интересно, кого оригинальный обладатель ника так сильно зацепил, что тот принялся столь
> бездарно подставлять поха, попрошайничая о взломе сервера?Точка на конце ника "немного намекает", что это - еще не оригинал:
https://www.opennet.dev/~%D0%CF%C8
https://www.opennet.dev/~%CE%C1%C8Бездарные современные опеннетные lапчатые, у которых бомбануло, но возразить по существу оказалось нечего, остались только детсадовские приемчики.
У мну - точно так же многолетний акк "залочили", из под следующего (и похожих) - откровенные глупости писать стали ... тфу.
Я их не по лишним точкам различаю.)) Вот тут похож на оригинального https://www.opennet.dev/openforum/vsluhforumID3/124593.html#114
хоть и мало написал.
> Кто вообще обновляет это ядро? В андроид по 5-7 лет стоит обрубок и ничего. Никому не нужен этот ваш линукс.И дыры размера с тоннель для бронепоезда.
> И дыры размера с тоннель для бронепоезда.Я ж говорю, никому не нужен этот ваш линукс
>В андроид по 5-7 лет стоит обрубок и ничего. Никому не нужен этот ваш линукс.У тебя древняя Нокия, у меня кнопочник. Так да, можно рассуждать про ненужность Линукса на телефоне.
То что ядро совсем не подходит для мобильной платформы, непонятно только самым упёртым
Ну и где QNX, который подходит? А может дело всё же в софте и удобстве разработки? Запускать любой обычный софт на телефоне вполне полезно. Вот что не подходит, так это жава -- батарейки то не резиновые.
QNX6 поддерживал и нативную разработку (был и компилятор gcc, и своя среда разработки, построенная на Eclipse), и ARM-овские процессоры (правда не помню, было-ли это одновременно), но был сильно платный, как для разработчиков, так и в использовании (необходимо отчислять за каждое проданное устройство). А так, архитектурно, был очень неплохой.
QNX тем более не подходит.
> QNX тем более не подходит.Почему же? Блэкбери сдох только сиараниями гугла, симбиан он вполне затыкал.
"Автор оптимизации решил проверить, насколько изменится производительность после отключения защиты от Spectre. После загрузки системы с параметром "mitigations=off" время выполнения "rr sources" без оптимизации составило 2 минуты 5 секунд (в 1.6 раза быстрее), а с оптимизацией - 33 секунды (на 9% быстрее). Интересно, что отключение защиты от Spectre не только в 1.4 раза сократило время выполнения кода на уровне ядра (c 2m9s до 1m32s), но и в два раза уменьшило время выполнения в пространстве пользователя (c 1m9s до 0m33s), предположительно из-за снижения эффективности работы кэша CPU и сбросов TLB при включённой защите от Spectre."Всего пара процентов, говорили они...
И это афтар еще не пробовал сравнить ведро, где защиты нет в принципе от ведра с "mutigations=off" (ведь очень нужно и полезно в самом-самом time-critical месте ядра проверять миллион этих идиотских флажков - впрочем, там еще и архитектурно все изуродовано).
mutilations?
Не забываем про ноутбуки и не самые новые компы. Там наверное от отсутствия нормальной кеша страдания будут посерьезнее. Вместо того чтобы исправить уязвимости их пока заткнули. Потому что вместо работы кеша происходит отрубание оного, что как бы не может быть хорошим решением в конвеерной инфраструктуре. Создаваемые процы были рассчитаны только на работу с кешем, а не с кривой реализацией.
*нормальной работы
Он на Skylake (дырявое недоразумение) тестировал, на современных процах падение производительности минимально.
Какая гадость эти ваши новые версии ядер.
А ведь проблема хардверная..
Проблема в ДНК.
Напихать в ведро ЖИТов, позволяющих напрямую исполнять левый код, а потом удивляться, ой, ачо в них дыры-то.
А зачем позволять не руту загружать BPF-код? Может, обычным пользователям позволить и модули ядра грузить?
Вообще-то хотелось бы уже нормальный фврйвол в линуксе увидеть, в венде ещё 20 лет назад фаревол лучше был (а может и до того), и это только штатный -- сторонние были ещё мощнее.
А вы видели, какие правила генерит GUI-морда этого лучше-файервола? Оно потом действительно так делает, как вы задумали? И я не видел. Правила iptables хоть видно.
Ну я любитель tinywall и да там всё работает как должно, просто штатный интерфейс не слишком удобный.
> я любитель tinywallhttps://tinywall.pados.hu/faq.php
"For completely other reasons though, it is recommended you leave Windows Firewall enabled." - чо ???лучше бы ты был любителем ком.строки, там где-то есть .exe для управления встроенным фаером. или netsh или ipsecpol как-то так.
> в венде ещё 20 лет назад фаревол лучше былДля тех, кто не успел родиться: 20 лет назад "Венды" то и не было. 98 и Millenium это такая надстройка над MS DOS.
Лучше я подожду фантастический рассказ на тему, где Аноним это использовал.
"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
Вот где не лузеры http://www.online-solutions.ru/products/osss-security-suite....
Но Микрософт решила, что там файрволл слишком много даёт пользователю, да ещё и обновления может определить как вредоносную активность. Потому 10-ки нет в списке. Лет пять работы коту под хвост.
Туго с фантазией? Лан, не напрягайся. Докопирую за тебя со страницы, где ты расширил свой кругозор: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".
Ты хочешь сказать, что бессмыслено тебя учить, что за слова следует отвечать? Так я не тебя учу. Ты лишь служишь примером.
Если бы твоё мышление не было бы столь фрагментарно, если бы ты мог не терять контекст и помнить свои сообщения на 1-2 назад, то ты бы знал, что заявил ты буквально следующее:"20 лет назад фаревол лучше был". https://www.opennet.dev/openforum/vsluhforumID3/124593.html#57
В доказательство чему ты привёл дату выхода Windows 2000 "General availability February 17, 2000"
которая не имеет отношения к твоему заявлению.Теперь ты пытаешься сплести _обрывки_ фактов, которые я заботливо тебе предоставил, что бы ты написал "судя по приведённому фрагменту". Действительно, по чему ты ещё можешь судить? Ты XP без SP в глаза не видел и не знаешь, что дата выхода и дата начала массового использования это две большие разницы. Это мы даже не учитываем, что из себе представляла функциональность тогдашнего Internet Connection Firewall, который тебе хватило ума приравнять к современенному.
Да, для тебя вообще без разницы и не имеют ровно никакого значения, что ты тут пишешь. У тебя был шанс дать ссылку сразу на XP. Если бы ты был хоть немного в теме, ты бы им воспользовался.
> А ты не любишь признавать свою неправоту, да?Я легко признаю, что я ошибся и ты не балабол, когда ты сможешь доказать своё исходное утверждение.
>> Я легко признаю, что я ошибся и ты не балабол, когда ты
>> сможешь доказать своё исходное утверждение.
> Только после того, как ты докажешь своё.Для неуспевших родиться: этот приём демагогии называется "переложить бремя доказательства на оппонента".
Так ведь, ты сказал, буквально, что в 2001 никаких nt не было, и были только дос и надстройки. На что я заметил, что 2000 уже определённо была (и была она даже до me которую никто в своём уме не использовал), а xp там была позже и я вообще уверен был что ближе к 2003, а не в 2001, что уже никак не тянет на 20 лет (хотя проблема и не в этом). Насчёт висты, впрочем, я был уверен, что в 2006, а она в 2007 (когда я её видел уже повсеместно, как это возможно, если она только появилась в продаже? что-то подсказывает мне, что это дата, когда она уже установлена на всех оем устройствах в мире).Про файерволы разговор отдельный, я прекрасно в курсе какая дрянь была 2000 и что до кучи патчей и обновлений она была не слишком юзабельна (а вот xp вполне себе по меркам того времени).
Возраст это для тебя очевидно болезненная тема, так что мой "совет" про "повзрослеть" тут пришёлся к месту.
> Так ведь, ты сказал, буквально, что в 2001 никаких nt не былоВот опять ведь обманываешь. Буквально -- "Венды". NT так и называли -- NT. Я даже знал тогда аж целых двух админов, кто её админит.
Впрочем, мы отвелелись. Тебе следует доказывать наличие файерволла, а не вопрошать "а нас за шо?"
Ты издеваешься? "Буквально" означает "в переносном смысле", у тебя как вообще с русским языком, нормально?Далее. В икспи его не было? Икспи была 20 лет назад, но я видел только сп1 (что уже 2002 или 2003, что впрочем разница в 5-10%). Как тут верно заметили в соседней ветке, до висты что ли, файрвол был достаточно теоретический, однако и он был и он был на голову лучше того, что имеет линукс сегодня (с пользовательской точки зрения).
Динамический файрвол всегда лучше и удобнее статического, но дело не только в этом.
> "Буквально" означает "в переносном смысле"1. нареч. к буквальный; точно соответствуя чему-либо, дословно
2. перен., разг. в знач. частицы действительно, на самом деле, прямо-таки
3. перен. в прямом смысле словаhttps://ru.wiktionary.org/wiki/буквально
> Ты издеваешься?
Да, ты это заслужил.
> Далее. В икспи его не было?
Доказательство твоего утверждения -- это твоя головная боль.
> до висты что ли, файрвол был достаточно теоретический
Ой, взял сам себя и опроверг. ;)
Спасибо, что процитировал, теперь перечитай 2 пункт, по-слогам.>ты это заслужил
Orly? Судя по тому, что ты и читать можешь только по-слогам, у меня есть определённые вопросы.
> Спасибо, что процитировал, теперь перечитай 2 пункт, по-слогам.Твоя просьба должна выглядеть так: "объясните, пожалуйста, смысл словарных сокращений".
2. перен., разг. в знач. частицы действительно, на самом деле, прямо-таки
Переносными значениями в разговорной речи, когда слово "буквально" употребляется в значении частицы, являются: "действительно", "на самом деле", "прямо-таки".
> Orly? Судя по тому, что ты и читать можешь только по-слогам, у
> меня есть определённые вопросы.Извини, я не знаю, почему ты такой глупый.
Ты только и делаешь, что агрессируешь, это уныло и ничуть не красит. Самое интересное, что считаешь себя правым, даже когда я объяснил свою позицию доходчивым образом и уже самое время осознать свои ошибки. Появилось ощущение, что гадишь в комментах ты не по фану, и это скорее какое-то расстройство. Я не специалист в этом вопросе и не могу судить.
Реальность такова, что не обязана всем нравиться: https://youtu.be/97ghLVUhtUw
> А всё дело в том, что 5 лет разницы не имеют ровно никакого значения.Давайте-ка уберу Ваш выхлоп, который как раз и не имеет ни смысла, ни значения. Благодарить можете сразу в спортлото, вот так же повиливая.
Ну-ну, ты в своём репертуаре.
> Давайте-ка уберу Ваш выхлопочень зря. любители щелкать чекбоксы в гуе должны страдать.
теперь и не докажешь ничего.
Да не, не торопись. Сначала дай ссылку, где написано про файрволл NT 3.1. ;)
> и это только штатный -- сторонние были ещё мощнее.И элементарно обходились в юзерспейсе самого приложения (Tiny/Kerio), потому что "работали" через инъекцию DLL ...
не-рут становится рут через атаку локал рут.
а этих локал рутов в ядре на 100 лет вперед припасено.
Речь-то шла о законной возможности загрузить в ядро какой-то код. Но если эта возможность даётся только руту, то он, по определению, способен думать, что он туда вгружает.
давно такого не было и вот опять.Кстати как там с защитой в 11 поколении Интела дела обстоят?
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
Вот говорили аноны от любителей до профессионалов: не тащите вы в рот какашку...Рукалицо &-(
iptables и nftables имеют фатальный недостаток - написаны не ими
И, что ещё хуже, неугодны системде
Кстати, nftables тоже свой байткод генерит, который исполняется своей виртальной машиной в ядре.
Многие тут даже не знают что и в SQLite используется виртуальная машина
И давно ли SQLite работает в пространстве ядра? :D
Погодите, и это притащат.
> iptables и nftables имеют фатальный недостаток - написаны не ими
> И, что ещё хуже, неугодны системдеВся эта мышиная возня делается с целью оптимизации, т.е. хотят сэкономить на персонале.
Но скупой платит дважды. Хапуги этого не понимают, никогда не могут вовремя остановиться.
BPF в ядре -- это вообще не про замену netfilter. Это невозможность отлаживать локальные приложения, скорее.
автозамена. невозможность => про возможность
А можжет это вендорское уг bpf выкинуть и все? Аааа ну да у хомяков мозг уже промыт.
Доскеры ж не смогут свой костыль под файрвол тогда подкладывать, беда-печаль.
> Доскеры ж не смогут свой костыль под файрвол тогда подкладывать, беда-печаль.да вроде как-то пока справляются, у них вообще только через старый iptables апи все нормально и работает (редхатовская ре-имплементация не в счет). Компания же ж банкрот, кто там что переписывать теперь будет?
BPF -- это не про netfilter. И Docker-у BPF для работы не нужен. BPF -- это скорее инструмент хорошего сисадмина, позволяющий отлаживать неотлаживаемое.
Какой уровень специалиста нужен, чтобы этим способом ломануть рабочую станцию? И что вообще он может выудить такого, о чём я должен беспокоиться?)
Как по мне, так рандомное чтение крошечных фрагментов памяти (пускай и занятых) это фигня - косяк конечно постыдный, но никто не пострадает.
В ютубе есть канал BlackHat, где есть демонстрации атак с попаданием/промахом в кэш. Это уязвимость другого сорта, но суть одна — прочитать память другого приложения (или библиотеки) непривилегированным кодом.
Надо ведь продавать новые компы, вот и выдумывают всякую ерунду для замедления, прям как в Огрызке, что не новая версия, так замедления "старых" устройств.
Так, может, лучше честно просто отказаться от спекулятива в процессорах? Тогда и костыли по замедлению не нужны будут.
Напомните, кто в курсе, на PPC64 это всё распространяется?
Проверьте# 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
> # 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Главное - верить!
Раритета. ;)
PPC 601?
Ну не настолько. Atom N270.
Огромная куча кода разного качества, каким-то чудом работающая, в которую ежедневно-постоянно вносятся исправления с новыми ошибками, которая "протухает" в лучшем случае еженедельно, созданная по принципу "Х**к х**к и в продакшн". Да, это всё наш Linux. А всё от того, что программистам хочется кушать.
Да, это всё наш Linux, MacOS/OSX, Android, Windows, и прочие BSD... извините, если кого забыл.А так же микрокод Intel, AMD, Nvidia, ARM и ещё несколько... только не еженедельно а 3-6 месяцев.
Добро пожаловать в 21 век, где бабло окончательно побеждает зло и готовится победить здравый смысл.
Покажи мне здесь 3-6 месяцев:
https://github.com/archlinux/svntogit-packages/commits/packa...
Сижу на 4.9, протухать и не думаю.
Пора переходить на RISC-V.
curl https://make-linux-fast-again.com
