The OpenNET Project / Index page

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



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

Оглавление

Уязвимость в подсистеме netfilter, позволяющая выполнить код на уровне ядра Linux, opennews (??), 22-Фев-22, (0) [смотреть все]

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


34. "Уязвимость в подсистеме netfilter, позволяющая выполнить код..."  +1 +/
Сообщение от Ordu (ok), 22-Фев-22, 15:45 
Справедливости ради стоит отметить, что тогда ещё говорили о том, что вообще нельзя писать систему на высокоуровневом языке, потому что тормозить будет. C смог пролезть в системное программирование потому, что он позиционировался как кроссплатформенный ассемблер.

Ну и да, тогда проверка границ была дороже: компиляторы были тупыми, подметить что условия цикла гарантируют, что проверка всегда даст true и вышвырнуть её за ненадобностью, они не могли. Да и языки были другие -- итераторов нет, лямбд нет, а значит нет способов свалить на массив организацию цикла так, чтобы с минимумом проверок. И спекулятивного выполнения тогда не было, чтобы эта проверка задним числом выполнялась бы параллельно с выполнением другого кода.

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

134. "Уязвимость в подсистеме netfilter, позволяющая выполнить код..."  +/
Сообщение от Аноним (-), 23-Фев-22, 19:02 
Даже сишный компилер может мастерски изгадить код, тормознув в пару раз на ровном месте. Или, наоборот, удалить "ненужных" проверок NULL, прувер штука такая, докажет "never happens" на раз, и пофиг ему что full view большой системы где-то уже продолбали.

Если код раз в день выполняется - черт с ним с всем этим, но ядро выполняет вообще все запросы программ и ворочает БОЛЬШИМИ потоками данных.

Есть юзеры с 8K дисплеями, NVME всякие, 100GigE - и их обладатели считают что это должно работать на скорости железа. Четвертинка от этой скорости их вообще совсем не устраивает.

А за спекулятив мы получили спектры с мельдонием, когда оказаолсь что задним числом оно эвона как, проц на допинге попадается.

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

135. "Уязвимость в подсистеме netfilter, позволяющая выполнить код..."  +/
Сообщение от Ordu (ok), 23-Фев-22, 19:34 
> Даже сишный компилер может мастерски изгадить код, тормознув в пару раз на
> ровном месте.

На это есть профайлер.

> Или, наоборот, удалить "ненужных" проверок NULL, прувер штука такая,
> докажет "never happens" на раз, и пофиг ему что full view
> большой системы где-то уже продолбали.

Это не было проблемой, пока C был кроссплатформенным ассемблером. Он генерил машинный код максимально приближенный к C'шному.

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

138. "Уязвимость в подсистеме netfilter, позволяющая выполнить код..."  +/
Сообщение от Аноним (-), 23-Фев-22, 19:45 
> На это есть профайлер.

Как вы себе это представляете на штуках типа линукс кернела в среднеотфонарных конфигах, работающих для вон той толпы народа? И что делать с комбинаторным взрывом и тем фактом что для одних лучше так, а для других эдак? Реально оно приходит к неким компромиссам, а что-то такое более реально для секурити типа kasan толпой ботов.

> Это не было проблемой, пока C был кроссплатформенным ассемблером. Он генерил машинный
> код максимально приближенный к C'шному.

Всего лишь это сейчас уже никого не устраивает. Крутой оптимизатор может намного больше. А если можно выжать больше из того же железа... нет, бизнес совершенно точно свою халяву никаким концептуалам не подарит. Ничего личного, это бизнес и это их бабки. А докупите на 10% больше серваков - за это в ином энтерпрайзе так то можно на мороз уйти. Другого нанять дешевле будет.

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

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

140. "Уязвимость в подсистеме netfilter, позволяющая выполнить код..."  +/
Сообщение от Ordu (ok), 23-Фев-22, 19:56 
Я не понимаю о чём ты споришь. Речь идёт о том, что "вас же предупреждали, что надо выход за границы проверять, а вместо этого вы десятками лет баги ловите". Вот когда предупреждали дешевизна проверки на выход за границы была очень неочевидной. Ситуация сейчас изменилась, и я не спорю с этим.
Ответить | Правка | Наверх | Cообщить модератору

142. "Уязвимость в подсистеме netfilter, позволяющая выполнить код..."  +/
Сообщение от Аноним (142), 23-Фев-22, 22:52 
> "вас же предупреждали, что надо выход за границы проверять, а вместо
> этого вы десятками лет баги ловите".

Все хотят и рыбку съесть и косточкой не подавиться. С растом столько возятся в основном потому что он похоже на это смотрится благодаря паре интересных идей. И меня так то устроит если компилер математически докажет "never happens" и выпилит проверку. Если оно стопудово так. Это даже желательно. Проблемы начинаются когда он что-то профакапил, упс...

Там вон еще некий ZIG вылупился, для сишного кода как-то логичнее как путь апгрейда смотрится, радикально переписывать не надо а секурити может улучшить.

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

Ну попробуйте с пакетами в 100Г сетевку или NVME так. IO с тех пор тоже не стоял на месте. Можно поискать историю с PPS и IOPSами в паре последних ядер, начните на форониксе, они такое любят.

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

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

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




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

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