URL: https://www.opennet.dev/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 128664
[ Назад ]
Исходное сообщение
"Уязвимости в беспроводном стеке ядра Linux, допускающие удалённое выполнение кода"
Отправлено opennews , 13-Окт-22 22:13 
В беспроводном сетке (mac80211) ядра Linux выявлена, серия уязвимостей, некоторые из которых потенциально позволяют добиться переполнения буфера и удалённого выполнения кода через отправку точкой доступа специально оформленных пакетов. Исправление пока доступно только в форме патча...

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

Содержание
Сообщения в этом обсуждении
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 13-Окт-22 22:13 
Это не баг, а фича для большого брата...
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 13-Окт-22 22:42 
Коммитишь баг в ядро / сетевой стек. Ждёшь, когда смёрджат в андроид или хромос. Обращаешься в гугл, получаешь бабки.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено anonym444 , 14-Окт-22 01:46 
Таки наш человек. Две мацы этому гсоподину
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 14-Окт-22 12:30 
Был бы наш слил бы сначала на сторону пятку разных клиентов, неофициально. А потом можно уже и гуглу.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено onanim , 14-Окт-22 17:29 
таки у Cellebrite эксплоиты ещё три года назад были, у Vupen - два, а у ZDI - год
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено penetrator , 14-Окт-22 04:33 
А что ведро уже на 5-ое ядро переехало? линейка например на 4.19
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 14-Окт-22 05:24 
Линейка и на 3 версии есть. Это от модели зависит, на каком ядре вендор выкатил такое и в линейке будет.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 14-Окт-22 12:37 
При желании можно и на 2.6.32 найти что-нибудь винтажное. Но зачем?
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 14-Окт-22 09:39 
https://source.android.com/docs/core/architecture/kernel/and...
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 17-Окт-22 11:10 
Эх, не хотел ведь, но придется набросить...

Идея, похоже, не нова, а потому принята во внимание. Гугл уже не вчера начал там блютуз-стек и IPC для Андроида на расте переписывать. Насколько там продвинулись, заменили ли - не знаю. Года полтора назад новость была. Для фуксии там тоже блютуз на расте писали, но отдельный проект.

"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 14-Окт-22 00:56 
Теперь линукс переустанавливать, а то мало что там провайдер отправил на роутер, который получил над моей (?) системой
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено А , 14-Окт-22 09:19 
Смени пароль с заводского на другой на роутере. А то операторы связи не делают этого...
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 14-Окт-22 10:07 
TR-069?

Нет, не слышад.

"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Anonymus , 14-Окт-22 14:07 
Отключи удалённое управление.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено А , 14-Окт-22 16:24 
Это пароль для входа в локалку. Любой под окном у стены может зайти в сеть и погнали...
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено onanim , 14-Окт-22 17:30 
на многих роутерах оно не отключается
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 15-Окт-22 16:42 
OpenWRT залей, там будет управление по вкусу.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено А , 14-Окт-22 16:23 
> TR-069?
> Нет, не слышад.

Провайдер называется по другому.

Пароль даёт, смотрю - чёт напоминает. Годами стандартный пароль, когда-то его видел где-то.

"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 13-Окт-22 22:19 
Надо было ставить OpenBSD.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 13-Окт-22 22:26 
Будто это возможно за пределами виртуалки, ага.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Массоны Рептилоиды , 13-Окт-22 22:52 
Нет wi-fi - нет и дырок
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 14-Окт-22 08:25 
Не зря его в офтопике отменили.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 15-Окт-22 15:46 
> Нет wi-fi - нет и дырок

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

"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 13-Окт-22 22:21 
Да что же это такое? Снова диды-сишники не те попались, а то гляди и вообще растоманы специально подстроили.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 13-Окт-22 22:45 
> начиная с ядра Linux 5.1

Какое отношение диды-сишники имеют к этому уязвимому коду написанному студентами из Индии?

"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 13-Окт-22 22:52 
А на ревью кто сидит? Да и не стоит забывать о недавней новости, когда в ядре нашли уязвимость времен динозавра. А это значит, что за 20+ лет ни диды, ни молодые Индусы не научились нормально писать на Си. Тогда какой выход остается, если никто не умеет писать на Си?
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 14-Окт-22 00:05 
Единственно правильный вывод, на ядро на Си должны писать эксперты с опеннет
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 14-Окт-22 12:38 
Слу, чувак, динозавры вообще вон вымерли. Вот это уязвимость так уязвимость. Ты, кстати, уверен что живешь в местности не интересной термоядерным ракетам?
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 14-Окт-22 03:25 
Ядро не ревьювят, его тестируют на пользователях.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено leap42 , 14-Окт-22 05:38 
> Тогда какой выход остается, если никто не умеет писать на Си?

Увеличить количество платформ на которых Rust имеет Tier 1 support в 20 раз(!) и переходить на него? Только "диды" и индусы этим заниматься не будут. Так что подождём ещё 10 лет. А там уже и что-то новенькое появится, впитает лучшее из Rust, а худшее не впитает. На него и перейдём.

"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено истина в последней инстанции , 14-Окт-22 15:34 
> Увеличить количество платформ на которых Rust имеет Tier 1

Вы уже написали растоос. Она даже не заводиться. Сколько лет вы её пилили? А за сколько на нормально языке linux первой версии завёлся?

То-то и оно. От вас только <>издаболство

"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено y , 14-Окт-22 18:47 
аминь
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Herrasim Muhmuh , 14-Окт-22 06:50 
Единственный в мире Си тру-дида - Си Дзин Пин
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 14-Окт-22 11:26 
Чемодан, вокзал, Пекин.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 14-Окт-22 08:27 
У дидов-то, конечно, ни разу дырок не было.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 16-Окт-22 17:04 
Как удобно: хороший код диды пишут, а плохой — только студенты из Индии. Эталонный манямирок.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 14-Окт-22 09:10 
Чтож растоманы то до сих пор не осилили переписать ядро на раст? Да чего уже там чего они свой вебдвижек Стерво до сих пор не переписали?
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 14-Окт-22 09:55 
Writing an OS in Rust: https://os.phil-opp.com/
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 15-Окт-22 15:44 
> Writing an OS in Rust: https://os.phil-opp.com/

Ну так себе операционочка, скажем прямо. Редокс тогда какой чтоли уж, не? Но пример bare metal кстати нормальный. Но между нами, на сях канители с ЭТИМ - в разы меньше чем вон там. Где, конечно же не обошлось без ночнушек, rustup и прочих характерных "прелестей". А, и линкер, кажется, gcc'шный. Так что заодно вы еще и половину гнутого тулчейна, ну или шлангской мимикрии под него всяко изучите при вон том желании. Без этого вы даже бинарь керенела себе не сделаете.

"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 16-Окт-22 17:11 
Действительно, нет бы заранее написали весь софт на расте идеально, без багов и с полным паритетом по фичам, а потом уже начали про раст рассказывать!

Вчерашним навроде тебя невдомёк, что без «характерных прелестей» в этом мире ничего стоящего не создать.

"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 17-Окт-22 13:56 
Спасибо за инновационные велики с квадратными колесами, конечно, но я уж лучше по старинке на круглых, пневматических.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Без аргументов , 14-Окт-22 16:33 
Вижу, что око овертона перешло в еще большую деградацию за последние 2 года. Сначала фу, потом толер, потом вкусно. Чем больше пугаете невежей, тем проще вбросить ржавчину.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено InuYasha , 13-Окт-22 22:32 
А что, ещё кто-то пользуется радио для связи? *trollface*
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 13-Окт-22 22:34 
Android
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 13-Окт-22 22:47 
Слава богу, можно будет хотя бы получить права владельца на своём личном телефоне.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 13-Окт-22 22:56 
Идеальная ирония IT мира в 2022 )))
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 14-Окт-22 04:28 
Да уж, и брендов позволяющих анлок становится все меньше и меньше.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 15-Окт-22 17:38 
Так и желания собирать кастомные прошивки с годами тоже не прибавилось. А как подумаешь, что нужен он только чтобы звонить, в телегу писать, карту и музыку в машине показывать и ещё на опеннет комменты с толчка строчить, то впору задаться вопросом: а стоит ли овчинка выделки ради пяти проприетарных прилаг? В итоге, нехай гугл прошивку собирает, авось не облажается.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено InuYasha , 16-Окт-22 23:00 
Да это всё вообще ерунда. Проблема в банкстерах, которые на каждый чих СМС требуют.
Так-то я месяц без телефона спокойно жил. Даже радовался.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено count0 , 24-Ноя-22 07:25 
Пользуйтесь налом / криптой. Есть даже вывод крипты в нал, но только в Москве.
А ещё есть не наши банки, только никому.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 13-Окт-22 22:56 
Ничего, вот скоро раст втащат, заживём!
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 13-Окт-22 22:56 
Раст правда от этого всего спасает?
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 13-Окт-22 23:08 
Правда. Но как и в случае любой квантовой системы измерение меняет состояние, и проверить это утверждение не так просто.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 14-Окт-22 00:39 
Это тот пулл-реквест, где половина кода в ансейфах?
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 14-Окт-22 02:23 
Состояние меняет не измерение, а взаимодействие с этим состоянием. Что не удивительно, ведь с ним взаимодействуют. Пытаясь измерить.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Без аргументов , 14-Окт-22 16:38 
Психику он не спасёт. Т.к. недовольства, критика и ожидание хорошего в том, чего не имеется -- это системная проблема, поскольку даёт вторичную выгоду самому ничего не делать, и даёт чувство правоты и соучастия в этом нелегком деле по достижению непонятно какого идеала, лишь бы поругать то, что дают.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Без аргументов , 14-Окт-22 16:40 
Да, сразу люди станут очень внимательными, еще больше будут разбираться в системном программировании, регистрах процессора, не опечатываться и глаз будет круглосуточно не красный, а как кристалл. И алгоритмы будут сразу криптоквантовые.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 15-Окт-22 21:33 
Как минимум обращение к нулевому указателю и к уже освобождённой памяти просто так не скомпилировать
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Без аргументов , 14-Окт-22 16:41 
Разница в том, что когда будет panic, лучше от этого не особо. Прога просто вылетает. А что с ядром даже не интересовался.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 14-Окт-22 20:08 
Как раст втащат, так ядро начнёт память жрать как не в себя, и вам придётся купить новый комп.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Шарп , 13-Окт-22 23:30 
>обращение к уже освобождённой области памяти (use-after-free)

rust

"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 14-Окт-22 01:01 
А что насчёт использования файлового дескриптора после закрытия файла?
Использования ресурса после снятия эксклюзивной блокировки на него?
Удаление элемента из коллекции в процессе итерирования и неучёт этого при дальнейших итерациях?
Обращение к процессу после его завершения?

Это всё use-after-free в каком-то смысле. Раст от этого тоже защищает? Или он просто обучает программиста не париться по поводу use-after-free в случае с памятью, так что тот и в других похожих случаях не будет над этим заморачиваться.

"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Шарп , 14-Окт-22 01:12 
> Удаление элемента из коллекции в процессе итерирования и неучёт этого при дальнейших итерациях?

Такое может произойти в связных списках. А раст не осилил связные списки. Так что мимо. Просто признай, что ты растохейтер.

"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 14-Окт-22 01:52 
> раст не осилил связные списки

понятно, почему на расте сложнее хеловорлда не пишут.

"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 18-Окт-22 02:22 
Настолько не осилил, что LinkedList есть в стандартной библиотеке.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Rev , 14-Окт-22 01:14 
Да, если канонично писать на Расте, то защищает.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 14-Окт-22 01:53 
> канонично

причащаться и ходить на исповеди тоже надо?

"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 14-Окт-22 04:17 
он имел ввиду тотальное использование C, асма и сишных библиотек, а раст юзать только в качестве обёртки, ну и чтоб скобочек больше было
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 14-Окт-22 08:11 
Удалить элемент из коллекции при итерировании точно не получится - для этого должна быть одновременно mut ссылка (для удаления) и обычная для итератора. А такое отсекает компилятор легко. Это распространяется на все объекты(ресурсы, дескрипторы). На счёт завершенных процессов - хз, не сталкивался
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 14-Окт-22 17:27 
в расте Drain итератор есть
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 14-Окт-22 12:45 
Это всё моделируется через систему типов и дальше отслеживается при компиляции. См rust newtype pattern.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 14-Окт-22 12:57 
От всего перечисленного защищает, кроме последнего. Поскольку Inter process communication не определяется компиляторами и не должен.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено PnD , 14-Окт-22 17:54 
Ещё можно права на записываемый файл в "-1" выставить. Как один новоиспечённый сотрудник micro$oft, года 3 назад, когда ещё в RH работал. (Не слышно пока о его творческих успехах на новом месте. Не иначе как NDA.)
А что такого, это ведь не ошибка?
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 15-Окт-22 17:55 
Можно. И нужно. Иначе как ты узнаешь, что твоё ядро и рантайм на самом деле из соплей и веток, и не защищают ни от чего вообще?
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено freecoder , 15-Окт-22 22:59 
> А что насчёт использования файлового дескриптора после закрытия файла?

Если использовать File из std, то он закрывается автоматически при уничтожении объекта. Уничтожить объект File - единственный способ закрыть файл. Так как объект уничтожен, то использовать после закрытия нечего.

> Использования ресурса после снятия эксклюзивной блокировки на него?

В std и прочих библиотеках в Rust примитивы синхронизации пишут так, что они владеют объектом, который синхронизируют. И API примитивов устроен таким образом, что невозможно получить доступ к объекту без того, чтобы не получить блокировку (если предполагается изменение объекта). Снятие блокировки происходит при уничтожении объекта-гарда, но именно через него только и возможен доступ к исходному защищенному объекту. После уничтожения доступ к объекту получить не откуда.

> Удаление элемента из коллекции в процессе итерирования и неучёт этого при дальнейших итерациях?

Со стандартными итераторами в Rust невозможно удалить объект в процессе итерирования. Дело в том, что вы когда итерируетесь, вы должны заимствовать коллекцию по ссылке (изменяемой или неизменяемой). Но для удаления объекта вам также необходимо иметь изменяемую ссылку на коллекцию. Но в процессе итерирования у вас уже используется одна ссылка, а правила заимствования разрешают мутабельной ссылке быть только уникальной. Так что компилятор не допустит изменяемого обращения по ссылке, когда в скопе уже есть другое заимствование (на сам итератор).

> Обращение к процессу после его завершения?

Поясните, какие обращения к процессу вы имеете ввиду?

"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 14-Окт-22 09:52 
carbon
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 14-Окт-22 00:49 
А зачем точке доступа отправлять такие пакеты?
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 14-Окт-22 01:00 
Потому что её попросили?
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 14-Окт-22 15:19 
Затем что люди и их мотивы бывают разные. Например, есть довольно много желающих на халявный вычислительный ресурс.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 14-Окт-22 00:58 
Напомню, 5.1 релизнулось в мае 2019го, а 5.2 - июле того же года. Сейчас отктябрь 2022го, и все это время уязвимости RCE прекрасно себе жили...

Интересно, куда смотрели тыщщи глаз? Как настоящие си-погромисты это написали и пустили в релиз?

Ну и тот факт что все ошибки из-за рукожoпства с памятью... просто прекрасная вишенка на торте))

"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 14-Окт-22 01:48 
> куда смотрели тыщщи глаз?

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

"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 14-Окт-22 01:49 
> все ошибки из-за рукожoпства

странно, что тут до 5.1 рукожoпства не было.

"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 14-Окт-22 04:50 
Ты не поверишь, но 100% ошибок из-за рукожопства с памятью. Все программирование про работу с памятью
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 14-Окт-22 10:08 
Что за бред ты несешь? Есть куча логических ошибок с памятью никак не связанных.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено n00by , 14-Окт-22 12:41 
Если проверили условие и выполнили не те действия, значит прочитали память (даже разряд в регистре флагов - память) и неверно интерпретировали данные.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 14-Окт-22 15:31 
> Все программирование про работу с памятью

Расскажи это крипто на регистрах.

"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 14-Окт-22 11:24 
>Интересно, куда смотрели тыщщи глаз?

Ну так в винде подобные уязвимости так и остаются неизвестными

"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 14-Окт-22 16:23 
Это чрезвычайно важно! Особенно когда ты сидишь на винде!
А вот остальным от этого как-то ни холодно, ни жарко. Опустились до аргументов "а у них негров линчуют"...
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 14-Окт-22 18:55 
Нет, родной, это не про негров, это про то, что открытый код позволяет провести ревизию, а закрытый - нет.
И да, когда ты сидишь на винде, это иногда становится важно, чаще всего - внезапно.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 14-Окт-22 19:27 
Ну да, а вот сейчас это произошло не внезапно? Через N лет после бага?
Открытый код еще и позволяет это легко искать всем заинтересованным, а не сидеть часами в IDA.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 14-Окт-22 20:07 
Ну и сиди на винде или OSX, если тебе проприетарь кажется безопасней.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 15-Окт-22 13:39 
> Ну и сиди на винде или OSX, если тебе проприетарь кажется безопасней.

Там если описание апдейтов еще и читать - CVEшет так то еще и побольше. Людям свойственно ошибаться. А когда это дешевые индусы + дофига кода, можете угадать что получается в результате.

"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Annoynimus , 20-Окт-22 11:05 
> Нет, родной, это не про негров, это про то, что открытый код позволяет провести ревизию, а закрытый - нет.

Ога - "теоретическая ревизия". Это когда в теории ревизию провести можно, а на практике все сидят на дырявом коде. И успокаивают себя тем, что у кого-то там даже теоретической ревизии нет.

"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 14-Окт-22 07:27 
Драйвера в составе ядра круто говорили они.... боже какой же тормоз торвальдс что не слушал таненбаума
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 14-Окт-22 08:33 
И действительно, вот у танненбаума-то ядро всем ядрам ядро!
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 14-Окт-22 09:19 
Интел не даст соврать
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 14-Окт-22 12:39 
Ты отстаешь от моды, щас нужно предлагать переписать на расте
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 17-Окт-22 11:35 
> боже какой же тормоз торвальдс что не слушал таненбаума

А так бы тормозом была бы ОС. Я двумя руками за микроядра с вынесенным в юзерспейс остальным обвесом, но переключение контекстов о-о-о-очень дорого стоит.

А вот настоящее сокровище было бы, если бы мололит весь на безопасном языке написали с минимумом ансейфа и ассемблерщины - и скорость сохранится и кол-во ошибок "на 70% (ц)" сократится. 30%, конечно, останется, из-за нашей человеческой криворукости, ну когда там знаки больше-меньше перепутали или в каком-нибудь протоколе алгоритмическую дыру с ворота не увидели и т.п.

"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено n00by , 17-Окт-22 12:55 
> А вот настоящее сокровище было бы, если бы мололит весь на безопасном
> языке написали с минимумом ансейфа и ассемблерщины - и скорость сохранится
> и кол-во ошибок "на 70% (ц)" сократится.

Берите больше, кидайте дальше:

Отличительной особенностью данной ОС является использование идеологии программно-изолированных процессов (Software Isolated Processes, SIP), похожих на лёгкие процессы языка Erlang, общение между которыми происходит исключительно посредством сообщений. В отличие от традиционных ОС, защита таких процессов в Singularity производится не путём организации аппаратно-защищённых адресных пространств, а путём использования типобезопасного подмножества промежуточного языка (MSIL) и его верификации перед компиляцией в родной код процессора. Каждый SIP обладает своим объектным пространством, «сборщиком мусора» и средой периода исполнения. Для таких процессов не допускается совместное использование памяти, и они не имеют возможность модифицировать свой код, что усиливает гарантии надежности работы программы в SIP.

"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 18-Окт-22 08:55 
так торвальдс с танненбаумом о сингуларити спорили? Слона то я и не увидел... Кто о чем, а курка о просо.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено n00by , 18-Окт-22 13:23 
> так торвальдс с танненбаумом о сингуларити спорили?

Они не спорили, а спрашивали друг друга «какой сейчас год».

"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 17-Окт-22 15:03 
Очень врядли: ядро и так порезано на относительно независимые подсистемы и драйверы, так что главный профит от упрощения отельных субзадач не случится.

Зато будет комбинаторный взрыв на границе взаимодействий кучи процессов. Когда они начнут понимать друг друга по разному и это само по себе целый новый клсс вулнов.

"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 14-Окт-22 11:33 
По видимому в OpenWRT уязвмость останется до следующего релиза. А без релиза использовать нельзя - в нерелизных сборках включены жирные отладочные вещи, делающие невозможным использование на устройствах с 32 MiB RAM.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено 1 , 14-Окт-22 12:05 
откуда инфа?
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 14-Окт-22 12:33 
Из личного опыта. OpenWRT нужно почаще делать релизы. В случае уязвимостей - сразу же.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено 1 , 14-Окт-22 12:54 
ну с недавней в wolfssl они сначала сделали обновление, а потом через несколько дней выпустили релизы
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено 1 , 17-Окт-22 01:37 
вышли релизы openwrt с исправлениями
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 14-Окт-22 12:09 
Это жжжж неспроста.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 14-Окт-22 13:10 
Так у них и без релиза сборки обновляются. Уже все пофикшено.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено 1 , 14-Окт-22 13:35 
эти дыры вроде еще нет, не пофиксили
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Джон Макагонов , 14-Окт-22 14:14 
Весь пост толстый намек на раст. Сишники,  и иже с ними,  переходите на раст,  если не хотите остаться на обочине истории.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Без аргументов , 14-Окт-22 16:45 
> если не хотите остаться на обочине истории

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

"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Без аргументов , 14-Окт-22 16:48 
плохо написал. уточню: ваше маниакальное ожидание "вот вот, и будет переворот", здесь неуместно. Это я как Сишник говорю. Какие-то новые сферы разработки да, но не миллиарды человекочасов переписать.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 14-Окт-22 17:10 
Надо внедрять и развивать статические анализаторы, тогда и сишный код может быть вполне безопасный
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 14-Окт-22 22:40 
Что ж за 50 лет так ничего толком не внедрили?
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Без аргументов , 15-Окт-22 00:17 
Самолеты летают, стиралки стирают, ты пишешь через кучу сетевых устройств с прошивками. Ядерное оружие тоже на Си. НЕ внедрили. Женская логика -- ты никогда, ты всегда, ничего, всё.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 15-Окт-22 00:50 
Угу, только самолеты летают на Ада и Спарк, танки ездят на них же, банковская система на Коболе и Джаве.
На действительно ответственные части энергетики си тоже не пустили.
А вот в марсоходе есть, но там MISRA C с такими ограничениями, что с обычным си практически несравним.
А да, надеюсь и в ядерном оружии его нету, иначе нам всем капец.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Без аргументов , 15-Окт-22 11:50 
> надеюсь

надейся.
начитался статей то, но нигде не работал.
наши БПЛА тоже на крестах (там много узлов, от ПЛИС до Cortex-M и Cortex-A).

"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 15-Окт-22 23:34 
При чем тут бпла к яо?
То что у вас бпла из гoвна и палок и так понятно... Последние полгода весь мир ржет с этих аналогoвнетов - китайская комлектуха и микрухи с алиекспресса. И то не хватило, пришлось у бабахов клянчить.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 17-Окт-22 13:59 
Они все их делают примерно из того же самого. Иначе получается десять штук в год по супер цене. И оно все такое замечательное, только заканчивается в момент.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Без аргументов , 15-Окт-22 11:52 
Это в твоей Америке старье, т.к. они сделали намного раньше эти системы, и работает -- не трогают. О каком тогда уж сыром расте может идти речь? Вы противоречите.
И напротив, в РФ все эти госуслуги и онлайн банкинг, ФНС это топ в мире, такого больше нигде нет. Потому что сделали недавно на недавних технологиях.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 15-Окт-22 23:36 
Никто не противоречит. В самолеты и танки никто раст тянуть не будет, просто потому что там уже есть свое легаси. Разве что в какие-то новые разработки, но учитывая консервативность отрасли... это будет лет через 20-30.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Без аргументов , 15-Окт-22 12:04 
Вот крипту растоманы начали пилить вместо классического банкинга -- флаг в руки
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 15-Окт-22 13:37 
> Угу, только самолеты летают на Ада и Спарк,

Дооо, конечно, особенно фирмвари микроконтроллеров которые так то last line of defence.

"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 15-Окт-22 15:48 
> На действительно ответственные части энергетики си тоже не пустили.
> А вот в марсоходе есть, но там MISRA C с такими ограничениями,

Думаешь на аде нельзя вебмакачить? А чего тогда ариан5 убился? :)

"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено randomize , 19-Окт-22 13:21 
> А да, надеюсь и в ядерном оружии его нету, иначе нам всем капец

Переполнение буфера, и весь мир поделится на 0.

"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 15-Окт-22 15:38 
> Надо внедрять и развивать статические анализаторы, тогда и сишный код может быть
> вполне безопасный

Без некоторого ограничения исползования некоторых вещей не прокатит. В сорце нет аннотации намерений кодера местами. Особенно вокруг работы с указателями и проч.

Простой пример: проанализируйте валиден ли вот этот вот вызов memcpy() или он выносит что-то? А, там void* и указывать может в принципе куда угодно? Ну вот так вот. MSIRA подобные вещи просто запрещает, так разумеется безопаснее, но произвольную программу вы так уже не соберете. И кернел переписывать устанете.

"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Без аргументов , 14-Окт-22 16:46 
0.1% говорит что-то про обочину
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Джон Макагонов , 14-Окт-22 19:46 
Какие 0.1%? Нас значительно больше. А вам сишникам должно быть стыдно - за 50 лет не придумали нормального системного языка,  пишете свои дырявые программы на дремучем языке. Нет чтобы влиться в раст-сообщество,  внести свой вклад в развитие прогрессивного языка - вы лучше будете противостоять ему и поливать грязью на сие гениальное творение ума человеческого. Ведь концепция до боли простая - у каждого выделенного участка памяти есть свой владелец,  двух владельцев быть не может. Возьмите ее и внедрите в свой С,  будьте людьми.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 14-Окт-22 20:51 
Растаманы за 16 лет ещё не показали, что на расте можно создать что-то работающее.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 14-Окт-22 22:42 
Ну так у них есть еще 34 года
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 15-Окт-22 15:40 
> Ну так у них есть еще 34 года

Не, вот на минутку! Си был создан по сути для unix'а и заняло все это никак не 16 лет. А на хрусте есть редокс, но кому он сдался...

"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 15-Окт-22 22:47 
>> Ну так у них есть еще 34 года
> Не, вот на минутку! Си был создан по сути для unix'а и заняло все это никак не 16 лет.

Ну так попробуй попользоваться именно ТЕМ юниксом ...
> А на хрусте есть редокс,

Который и железа поддерживает поболее, да и сам умеет на порядок больше ...
> но кому он сдался...

А кому сдались "оналитические" вспуки на опеннете?

"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 17-Окт-22 14:01 
Им как минимум авторы пользовались. Да и линуксом его автор стал за месяц пользоваться. А сколько пользователей у этой штуки через годы?
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 17-Окт-22 23:01 
>>> Ну так у них есть еще 34 года
>> Не, вот на минутку! Си был создан по сути для unix'а и заняло все это никак не 16 лет.
> Им как минимум авторы пользовались. Да и линуксом его автор стал за месяц пользоваться.

А в огороде бузина.
Причем, кивать на "тот самый юникс, вон тогда появился!", но по фичам сравнивать с _современным_ пингвинчиком, плодом разработки тысяч п(р)огромистов и миллиардов $ вливаний - опеннетная оналитега во все её красе ...

> А сколько пользователей у этой штуки через годы?

Всяко поболее, чем у тех самых первых юниксов.

"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Без аргументов , 15-Окт-22 00:05 
ногодрыг GPIO же для одноплатника _переписали_ с Си.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Джон Макагонов , 15-Окт-22 02:12 
Языку Rust всего 7 лет. Версия 1.0 вышла в 2015 году. Тот год и есть год его рождения. И за эти короткие 7 лет его уже пускают в ядро,  пусть и на драйвера временно. А что у нас слышно про С++? Про Go? Про D? Плюсы пригодны только для аппликух - слишком много слоев абстракций. У раста нет классов,  нет наследования - зато есть грамотная система типов и трейтов. У go и d толстые рантаймы,  они тоже для аппликух только.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 15-Окт-22 09:42 
100 строк существующего драйвера переписать? Ты с головой давно поссорился? На всём кроме сраста давно уже тонны полезного софта.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Анонн , 15-Окт-22 10:19 
Особенно на D )))
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 15-Окт-22 23:57 

[27.11.2018] Amazon открыл код легковесной платформы виртуализации Firecracker
[16.09.2022] Cloudflare перешёл с NGINX на собственный прокcи Pingora, написанный на языке Rust


> Растаманы *пук!* за 16 лет *Пуууук!* ещё не показали, *Пук-пук-пук-пук!*

"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 17-Окт-22 11:48 
Они еще лет 20 подобное будут писАть. Даже когда вокруг уже будет густо обмазано растом и ядро будет иметь не одну сотню драйверов на нём.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Без аргументов , 15-Окт-22 00:10 
> Нас значительно больше.

Так думают все, кто замкнуто крутится в однообразной тусовке, это как автоподбор рекламы, контента и новостей создаёт сферическое мировоззрение (и мировосприятие) в вакууме.
Я признаю ошибку. 0.05%.
А по факту на HH: 73 вакансии «rust», 1 427 вакансий «C++» (2 714 вакансий «C разработчик»)

"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено аннонн , 15-Окт-22 00:56 
Ты бы еще посмотрел сколько нужно джаваскриптеров, пхпышников и, упаси господи, 1Сников.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Без аргументов , 15-Окт-22 11:58 
Демагогия -- это хождение по кругу без точки опоры.
Помогу: вы перечислили _прикладные_ вакансии для коммерческих компаний и сервисов, в них потребность выше, как в количестве пачек туалетной бумаги.
Один человек изобрел материнскую плату -- 10 человек ОС запилили, 100 человек софт под ОС. Но без первого те 100 -- зазнайки.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Без аргументов , 15-Окт-22 00:15 
> у каждого выделенного участка памяти есть свой владелец

С таким лютым ограничением это уже не язык системного уровня как Си. Потому что вы и знать не хотите устроен компьютер, а лезете в него: у него есть кольца защиты, сегменты памяти и т.п., но нет никаких прав на переменную в рамках одной программы. Как писать всякие загрузчики, критические места без этого... Это преимущество для обычной прикладухи, зачем, если был уже более безопасный с паниками Го и прочие Python с Java...

"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Джон Макагонов , 15-Окт-22 01:40 
Это все от лукавого. Язык С уровнем повыше будет,  чем машинный код или даже ассемблер. А если язык высокоуровневый,  в его компилятор просто должны быть зашиты лютые ограничения - просто надо подумать,  собраться вам всем и раскинуть мозгами. Но нет же,  вам легче поливать помоями тех,  кто пытается это делать хоть как-то. Раст тоже не дает 100% гарантий,   у него таки есть гребанный ансейф,  но он хоть что-то дает,  а  язык С ни дает вообще никаких гарантий - все на совести и чести программиста.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 15-Окт-22 09:45 
Делать хоть что-то это прыгать голым задом на ежа? Переливать воду из одного стакана в другой? Носить воду в решете? А чём польза этой бесполезной беготни с срастом? Головой не пытался думать что труд должен приносить результат? А не красит траву от забора и до обеда?
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Без аргументов , 15-Окт-22 12:01 
у нас есть общее: все хотят сделать нормальный софт, просто по-разному видят
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 17-Окт-22 14:03 
> а  язык С ни дает вообще никаких гарантий - все
> на совести и чести программиста.

Вообще, современные компилеры и статические анализаторы это немного научились. Равно как asan и ubsan. Так что это не на 100% верное утверждение.

"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Джон Макагонов , 15-Окт-22 01:53 
> Как писать всякие загрузчики, критические места без этого...

Через ассемблер. Есть все-таки участки,  куда нельзя пускать высокоуровневые языки.

"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено n00by , 15-Окт-22 09:24 
>> Как писать всякие загрузчики, критические места без этого...
> Через ассемблер. Есть все-таки участки,  куда нельзя пускать высокоуровневые языки.

На всякий случай попробую подтвердить голословное утверждение эксперта, приведу пример, где необходим «ассемблер», если не считать загрузчики:

.386
.model flat
?catchguardhandler@cxxrecord@cxxruntime@ntl@@SA?AW4disposition@exception@nt@3@PAUrecord@563@PAUregistration@563@PAUcontext@63@PAUdispatcher_context@563@@Z PROTO SYSCALL
.safeseh ?catchguardhandler@cxxrecord@cxxruntime@ntl@@SA?AW4disposition@exception@nt@3@PAUrecord@563@PAUregistration@563@PAUcontext@63@PAUdispatcher_context@563@@Z

Поскольку Rust декларируется как замена C++, интересно, как там решили данный вопрос?

"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Анонн , 15-Окт-22 10:00 
Для чего-то простого есть inline asm
https://doc.rust-lang.org/reference/inline-assembly.html
https://doc.rust-lang.org/nightly/rust-by-example/unsafe/asm...
Просто пишешь макрос asm!(...) в виде unsafe вставки в коде и все. Но там есть некоторые ограничения.

Плюс ты просто можешь использовать asm-файл. Для этого есть макрос global_asm!.
global_asm!(include_str!("../asm/stage_1.s"));
(взято отсюда https://github.com/phip1611/bootloader/blob/main/src/bin/bio...)

"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено n00by , 15-Окт-22 10:26 
Что бы ответить на мой вопрос, надобно понимать, что такое .safeseh и какое он имеет отношение к «нулевому рантайму». Впрочем, для Linux это не актуально.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 15-Окт-22 15:28 
> Что бы ответить на мой вопрос, надобно понимать, что такое .safeseh и
> какое он имеет отношение к «нулевому рантайму». Впрочем, для Linux это
> не актуально.

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

"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Анонн , 15-Окт-22 19:36 
Да, ты прав, не знал про такое - виндовая штука ¯\_(ツ)_/¯
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено n00by , 16-Окт-22 08:54 
Так вот остальное (если не считать загрузчики и специфичные моменты в ядре ОС) решается на Си++ без ассемблера. Не средствами из стандарта, но в компиляторах есть всё нужное. Соответственно и на Си решается.
"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено pavlinux , 17-Окт-22 13:25 
И ещё 100500 отмазок почему я так хочу.

... if (likely( if (unlikely(...))))

"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено n00by , 17-Окт-22 13:42 
> И ещё 100500 отмазок почему я так хочу.
> ... if (likely( if (unlikely(...))))

Потому что на IA32 одно время ввели префикс для условных переходов, а потом от него отказались. А приведённый пример как бы универсален, достаточно пересобрать при смене правил, а не переписывать, как пришлось бы на асме.

Assembly/Compiler Coding Rule 3. (M impact, H generality) Arrange code to be consistent with
the static branch prediction algorithm: make the fall-through code following a conditional branch be the
likely target for a branch with a forward target, and make the fall-through code following a conditional
branch be the unlikely target for a branch with a backward target.

"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено Аноним , 17-Окт-22 14:05 
> в компиляторах есть всё нужное. Соответственно и на Си решается.

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

"Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."
Отправлено n00by , 18-Окт-22 13:37 
Не знаю, что там за половина у одной машинной команды. Разница между интринсиками и инлайн асмом в том, что микрософтовский транслятор видит __asm nop и у него от этого отключается оптимизатор. С GCC получше, но надо три раза присесть, написав помимо мнемоник команд ещё и аннотацию.