The OpenNET Project / Index page

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

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


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

Оглавление

Уязвимости в подсистеме eBPF, позволяющие обойти защиту от атак класса Spectre, opennews (??), 22-Июн-21, (0) [смотреть все]

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


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ообщить модератору

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

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




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

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