Ситуация 1. Я взял у каждого по 1.1$.

Ситуация 2. Я взял N$ только у Васи, потому что эксперты-астрологи с хорошей репутацией сказали,… Это не страховая деятельность.

Неправда. Ситуация 1 невозможна. Никто в здравом уме не заплатит тебе 10% за страховку, только тот, кто знает, что проиграет.

На самом деле ситуации такие:

Ситуация 1. Ты берёшь по 6 долларов с каждого. 8 платишь за пиво вместо проигравшего (ещё 2 должен заплатить проигравший, должен же он как-то быть наказан), ещё покупаешь им колоду карт за 2 доллара и ещё каждый играющий имеет право заставить тебя купить ему чипсов на 1 доллар максимум. Если хочет чипсов, конечно. 40 долларов берёшь себе. Почему они соглашаются? Потому что обязательное страхование, закон такой, отказаться нельзя.

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

Как видишь, аудит вполне себе может входить в требования страховой, в обществе здорового человека именно страховая, а не пожарники, проверяют наличие огнетушителей и запасных выходов. А вот предложенная тобой «страховка» в виде кассы взаимопомощи существует только в пропаганде, когда лоббисты страховых пытаются протолкнуть очередное обязательное страхование на условиях, при которых они просто фактически получат на откуп дополнительный налог.

Белиссимо!

Думаю, бежать смысла нет. Во-первых, если кто-то хотел что-нибудь внедрить в ядро, то он, судя по всему, давно мог это сделать. Во-вторых, с учетом существования Intel ME и аналогов врядли можно уверовать в безопасность просто сменив операционную систему.

Решето

Я описал принцип работы страховой здорового человека. % зависит от деятельности. Активно практикующие хирурги в США в год по 200 тысяч долларов платят за страховку от врачебной ошибки.

Это не значит, что среди них нет игроков в казино, а правительство - некоррумпировано и не поддаётся лоббированию группами особых интересов. Только авторитетные эксперты тут не причём. Практика размытия ответственности за счёт привлечения как можно большего количества «экспертов» и подписания документа «треугольником» актуальна была только в СССР.

Уже не важно

Им пермобан в проекте ядра, и соответственно, что-то похожее сразу во всех OpenSource проектах. Заодно университет сделали знаменитым, так что и оттуда скорее всего уволят. Фамилии тоже лучше поменять, а то мало-ли, вдруг дядя который их на таможне проверять будет по выходным код коммитит. Почти гарантирован личный обыск по подозрению в чем угодно :) Тестированеи это хорошо, но допускать попадание внедренных люков в стабильную ветку - за это лица ломают.

Потому что нельзя провести полноценный аудит постоянно мутирующего монстра.

И тут корпорациям как попёрло! То есть сопровождающие жили в мирке розовых пони, мягких стен и добрых коммитеров все эти почти 30 лет?

Коммитящие код корпорации всё это время не были заинтересованы в ухудшении качества ядра.

Как это всё ты вычитал из процитированного ответа универа?

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

Да ладно место плакало в топ 50… Вон у Линукса вообще теперь репутация дырявого решета. Возможно китайцы его проверяли по заданию своего правительства, на тему того, можно ли доверять линуксу свои гостайны или нет. Вывод неутешительный - нет. Госдеп туда может на пихать свои поделия, и никто ничего не заметит.

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

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

два чая этому господину!

с учетом существования Intel ME да! именно так миникс и победил линукса! )))))

бежать смысла нет

Это не пипец?

с учетом существования Intel ME и аналогов

Уязвимости в ПО устранять вообще не нужно и бессмысленно?

уверовать в безопасность просто сменив операционную систему

Может и нет, но всё же в остальных OS тоже бывает смысл и польза.

Все в этой истории молодцы, все всё правильно сделали

А Windows это затронет /WSL2/?

Суть в том, что люди вносят уязвимости в ядро, после этого они доходят до stable, и затем эти же люди публикуют whitepaper об этих уязвимостях, не откатив их и даже не сообщив предварительно в ядро.

Our goal is not to introduce vulnerabilities to harm OSS. Therefore, we safely conduct the experiment to make sure that the introduced UAF bugs will not be merged into the actual Linux code. ...

Once a maintainer confirmed our patches, e.g., an email reply indicating “looks good”, we immediately notify the maintainers of the introduced UAF and request them to not go ahead to apply the patch. ...

In all the three cases, maintainers explicitly acknowledged and confirmed to not move forward with the incorrect patches.

Кому верить? Публикации или аналитикам с ЛОРа?

Мне можно, остальным нельзя!

почему не забанена организация, которая намеренно внесла уязвимость, просущестовавшую 5(!) лет

Ты про пример с int __mdiobus_register(...)? Если да, то откуда информация о том, что эта уязвимость была добавлена намеренно?

что еще за патчи _после_ pdf прислали. автор у них другой

Судя по публикации, изначальные патчи (с уязвимостями) преднамеренно слались с фейкового аккаунта. Или ты не об этом?

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

Я описал принцип работы страховой здорового человека. % зависит от деятельности. Активно практикующие хирурги в США в год по 200 тысяч долларов платят за страховку от врачебной ошибки.

Ты в своём уме? Как ты умудрился в одном предложении упомянуть хирургов в США и что-то «здорового человека»? Здравоохранение в США - это как раз тот самый пример «ситуации 1» из моего текста, когда под видом страховки выступает государственно-частное партнёрство по вымогательству денег. Вот тот самый случай, когда вместо страхования реального риска тебя заставляют покупать чипсы через посредника, забирающего себе нехилую маржу. Если интересно, набери в ютубе «milton friedman unions» и получишь запись от 70х годов примерно где умный лысый дядечка объясняет чем являются на самом деле профсоюзы. И в качестве примера он приводит как раз AMA - фактически профсоюз врачей, который совместно со страховыми под видом защиты здоровья пациентов добился взвинчивания цен на медицинское обслуживание на пару порядков. С тех пор всё только ухудшилось, в 80х всех работающих посадили на уравниловную страховку от работодателя, а недавно вон обамакер, который через несколько лет заменят на государственную ОМС. Медицинская отрасль США держит первое место по суммам на лоббирование, если не ошибаюсь. То, что хирургам приходится откатывать часть - это не имеет никакого отношения к страхованию вообще, просто какие-то мутки профсоюза со страховыми.

Только авторитетные эксперты тут не причём. Практика размытия ответственности за счёт привлечения как можно большего количества «экспертов» и подписания документа «треугольником» актуальна была только в СССР.

Ты не понял. Как раз твой схематоз по делению проигрыша на всех поровну - это и есть «размытие ответственности». Что в твоём примере про игру в карты «ответственность» если не 10 долларов проигрыша? Ты предложил поделить его на всех. Размазал ответственность.

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

Я тебе уже даже объяснял, твоя схема без монополии и принуждения вообще работать не будет, если ты попытаешься поделить проигрыш на число игроков и накинуть свои 10%, то нихрена у тебя не выйдет: все кто играют хорошо либо вообшще откажутся от страховки, либо пойдут в другую страховую, которая учитывает умение играть. Так что в реале ты перед каждой партией будешь получать 2.2 доллара и твои клиенты будут проигрывать в 90% случаев.

Можно сломать исследователям ноги для отработки оказания первой помощи

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

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

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

Проблема — не в узком месте. Все знают, что код-ревью не даёт 100% гарантии. Тут они ничего нового не сказали.

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

То есть вроде бы, всё хорошо.

Проблема не в исследовании, а в том, КАК они его провели:

Как они нашли СОТНИ бажных коммитов в ядро?

И всё выглядит так, словно они несколько лет СПЕЦИАЛЬНО отправляли в ядро бажные коммиты и смотрели, что будет: сколько багов найдут сразу, а сколько потом. Они, похоже, даже написали программу, которая генерирует бажные патчи, постили эти патчи в ядро, и смотрели, какие из нагенеренных багов девелоперы найдут.

Простая аналогия: я буду бросать в тебя кирпичи, а потом скажу, что просто исследованил от скольких кирпичей ты увернёшься. Ты же мне после этого не будешь угрожать физическим насилием, правда? Я ведь укажу тебе на твоё узкое место? 🙂

Нет, не так. Вы наводите тень на плетень и вводите в заблуждение пользователей лора.

Не исключено. Все могут ошибаться.

О возможности скрытого внедрения уязвимостей в программное обеспечение с открытым исходным кодом с помощью лицемерных (Hypocrite) коммитов

Пожалуй, лучше перевести не «лицемерных коммитов», а «притворных коммитов» — коммитов, которые притворяются, что исправляют что-то, а на самом деле вносят ошибку. Но, да.

Всё, что ниже в статье - развивает эту мысль.

А вот тут нет.

Ниже в статье текст выглядит так, словно они анализируют уже состоявшиеся и исправленные коммиты. Они приводят примеры таких коммитов (не их коммитов, просто чьих-то, один из примеров они взяли из презентации GregKH-а «CVEs are dead»).

То есть статья выглядит так, будто они проанализировали сотни чужих коммитов и отправили три своих («We submit the three patches using a random Gmail account to the Linux community»).

Но на самом деле товарищи с домена @umn.edu отправили сотни кривых коммитов, которые ничего не исправляли. И, похоже, именно эти свои же сотни коммитов они в статье и анализировили.

Получилось такое себе «обучение нейронки с учителем» — генерим баги и обучаем их распознавать. Только в качестве «нейронки» — девелоперы Linux.

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

Ну конечно, все всё знают, но никто не чешется. Лишний раз ткнули носом - а там реакция как на той картинке с роскомнадзором. Чистое поле и посередине дверь запертая.

Если переводить информационную безопасность в физическую, то есть видюшки про взлом замков и систем безопасности, показывающие узкие места. Авторов сажать в тюрьму?

Ну конечно, все всё знают, но никто не чешется.

Как же не чешутся?

Если они «не чешутся», то я даже не знаю, кто «чешется». 🙂

Разработана кучу инструментов, начиная от встроенных, вроде kasan и kmemleak, и заканчивая всякими Syzkaller-ами.

Причём исследователи (не сабжевые, настоящие) постоянно занимаются этим вопросом.
Например: Effective Static Analysis of Concurrency Use-After-Free Bugs in Linux Device Drivers

In this paper, we propose a practical static analysis approach named DCUAF, to effectively detect concurrency use-after-free bugs in Linux device drivers.

DCUAF combines a local analysis analyzing the source code of each driver with a global analysis statistically analyzing the local results of all drivers, forming a local-global analysis, to extract the pairs of driver interface functions that may be concurrently executed. Then, with these pairs, DCUAF performs a summary-based lockset analysis to detect concurrency use-after-free bugs.

We have evaluated DCUAF on the driver code of Linux 4.19, and found 640 concurrency use-after-free bugs. We have randomly selected 130 of the bugs and reported them to Linux kernel developers, and 95 have been confirmed.

Так поступают нормальные исследователи.

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

Если переводить информационную безопасность в физическую, то есть видюшки про взлом замков и систем безопасности, показывающие узкие места. Авторов сажать в тюрьму?

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

Ещё раз подчёркиваю, проблема — не в исследовании. Это хорошее исследование, и полезная тема.

Проблема в том, КАК оно было проведено.

Его могли провести так:
«Мы разработали инструмент, который находит места, где могут быть баги. Мы проверили эти места. И нашли несколько сотен багов. Сообщили их разработчикам. И дали им наш инструмент, чтобы они в будущем могли выявлять такие баги автоматически и сразу.»

Так они бы тестировали код ядра и улучшали его.

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

Так они тестируют людей и злят их.

Ну, вот и разозлили,

вместо разработки инструментов для поиска багов, занимаются издевательством

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

These patches were sent as part of a new static analyzer that I wrote and it's sensitivity is obviously not great.

тут список говнопатчей

https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh@linuxfoundation....

я мельком посмотрел, например

        // read status reg in order to clear pending irqs
-       sp8870_readreg(state, 0x200);
+       err = sp8870_readreg(state, 0x200);
+       if (err)
+               return err;

типичный говнопатч который ничего не исправляет

https://www.mail-archive.com/linux-media@vger.kernel.org/msg142381.html

In sp8870_set_frontend_parameters, the function sp8870_readreg may return an error when i2c_transfer fails. The fix checks for this error and returns upstream consistent with other invocations.

Signed-off-by: Aditya Pakki <pakki...@umn.edu>

We are not experts in the linux kernel and repeatedly making these statements is disgusting to hear.

https://lore.kernel.org/linux-nfs/YH/fM/TsbmcZzwnX@kroah.com/

интересно, вот раст в ядре появился, начнут такие Aditya Pakki писать драйверы совершенно не разбираясь во внутренностях ядра - кто их говнодрайверы будет проверять ? растоманов не так много а тех разбирается в ядре Linux среди них единицы.

Все могут ошибаться.

«Ошибаться» категория иного рода. Извините я ошибся, вот вам ещё 5 центов. В том сообщении, к которому обращён был мой пост было введение в заблуждение и неверная интерпретация исследования. Ещё раз.

Исследование фокусируется совсем не на том, что-де программисты часто допускают мелкие ошибки в коде Linux Kernel. Начнём с того, что исследование изучает конкретную тему: О возможности скрытого внедрения уязвимостей в программное обеспечение с открытым исходным кодом с помощью лицемерных (Hypocrite) коммитов.

Во главу угла ставится умысел.

не «лицемерных коммитов», а «притворных коммитов»

Hypocrite имеет устойчивый перевод и подразумевается именно лицемерие. Притворство это ближе к pretend и синонимам. Слово Hypocrite очень важно, посколько оно формирует смысл исследования - вредоносный коммиттер, незаметно внедряющий уязвимости [ЧЕРЕЗ ПСЕВДО-ИСПРАВЛЕНИЕ СУЩЕСТВУЮЩИХ УЯЗВИМОСТЕЙ], которые в течение длительного периода времени могут быть использованным злоумышленником для воздействия на огромное количество устройств и пользователей.

In this paper, we instead investigate the insecurity of OSS from a critical perspective—the feasibility of a malicious committer stealthily introducing vulnerabilities such as use-after-free (UAF) in OSS through hypocrite commits (seemingly beneficial minor commits that actually introduce other critical issues). Such introduced vulnerabilities can be critical, as they can exist in the OSS for a long period and be exploited by the malicious committer to impact a massive number of devices and users. Specifically, we conduct a set of studies to systematically understand and characterize hypocrite commits, followed b your suggestions for mitigation.

Выражения malicious committer, hypocrite commits наглядно описывают с чем имеют дело авторы исследования.

Девелоперам надоело тратить своё время на роль подопытной крысы

Хех. Девелоперы бы об этом исследовании и не узнали бы, если бы авторы исследования об этом сами не сказали. Подтверждение:

As a proof-of-concept, we safely demonstrated that introducing UAF bugs in the Linux kernel by submitting hypocrite commits is practical. Note that the experiment was performed in a safe way—we ensure that our patches stay only in email exchanges and will not be merged into the actual code, so it would not hurt any real users (see §VI-A for details).

Авторы исследования ведут себя как своего whitehats, предупреждая о своих изысках. Они могли этого не делать, но в таком случае это могло иметь неприятные последствия для конечных пользователей: will not be merged into the actual code, so it would not hurt any real users.

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

Они отправили свои патчи, которые представляли собой hypocrite commits. Суть в том, что их патчи в ядро были этими самыми stealthily introducing vulnerabilities. Они на практике показали, каким образом злоумышленник может вносить псевдо-исправление уязвимости, оставляя возможность эксплуатации.

Получилось такое себе «обучение нейронки с учителем» — генерим баги и обучаем их распознавать. Только в качестве «нейронки» девелоперы Linux.

Получилось следующее: девелоперам Linux на примере показали, что процесс проверки и code-review где-то на уровне ниже плинтуса и возникают множество вопросов, связанных с усложнённостью кода ядра, с ограниченными ресурсами для обслуживания кода, вопросы доверия к коду и тп.

kasan/kmemleak/Syzkaller

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

В том сообщении, к которому обращён был мой пост было введение в заблуждение и неверная интерпретация исследования.

Почему «неверная»? Какое из утверждений в том посте было неверным?

Там не была процитирована тема. И многие главы не были процитированы. Потому что это всё не связано с проблемой. В каком месте там «введение в заблуждение»?

Ещё раз — претензии не к теме исследований, а к методам его проведения.

Во главу угла ставится умысел.

Во главу темы — да. А во главу текста — нет. В тексте не написано «мы отправили несколько сотен патчей девелоперам чтобы собрать статистику», там написано «мы отправили три».

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

Исследователи соврали?

Подтверждение: As a proof-of-concept, we safely demonstrated that ...

Это не «подтверждение», а просто цитирование их слов. Почему этим словам нужно верить?

Авторы исследования ведут себя как своего whitehats, предупреждая о своих изысках.

Нет, никого они не предупреждали. Ну или попробуй найти в рассылке это самое их «предупреждение».

Хех. Девелоперы бы об этом исследовании и не узнали бы, если бы авторы исследования об этом сами не сказали.

Так девелоперам-то авторы и не рассказали. Девелоперы сами нашли это «исследование».

И это — одна из проблем. Из девелоперов сделали подопытных крыс, отнимая кучу ихнего времени, и без их согласия.

Получилось следующее: девелоперам Linux на примере показали, что процесс проверки и code-review где-то на уровне ниже плинтуса и возникают множество вопросов

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

А то может всё наоборот, и он не «ниже плинтуса», а «на очень высоком уровне»?

kasan/kmemleak/Syzkaller

Подмена понятий. Против нетривиальных hypocrite commits эти вещи не работают

А что работает? А то авторы сабжевого исследования предложили использовать именно их.

в главном проекте CS нашего времени А не много ли чести для груды копипасты, в которой и CS-то с гулькин нос?

Так девелоперам-то авторы и не рассказали. Девелоперы сами нашли это «исследование». И это — одна из проблем. Из девелоперов сделали подопытных крыс, отнимая кучу ихнего времени, и без их согласия.

Очень жаль. Но от внимательности этих людей зависят все, кто имеет дело с Линуксом. И проверить их внимательность оказалось самой логичной затеей за многие годы. В армии тоже проводят внезапные проверки, с целью выяснить боеспособность войск. И проверка выявила громадные проблемы в безопасности Линукса, которая зависит от настроения и внимательности его разработчиков. Для кого-то это было очевидным, а для кого-то это открытие, что в ядро Линукса можно внедрить все что твоей душе угодно. Тысячи глаз оказались красивой сказкой свободного сообщества разработчиков.

Очень жаль. Но от внимательности этих людей зависят все, кто имеет дело с Линуксом. И проверить их внимательность оказалось самой логичной затеей за многие годы.

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

В армии тоже проводят внезапные проверки, с целью выяснить боеспособность войск.

Сабжевая проверка в армии выглядела бы примерно так: для проверки внимательности войск мы каждый день в течение 2 лет подбрасывали гайку в еду случайного солдата и смотрели, сколько её найдут, сколько сломают зубы, и т.д.

Не особо-то ценная проверка...

И проверка выявила громадные проблемы в безопасности Линукса

Да нихрена она не выявила. В этом отношении исследование почти бесполезно.

Во-первых, оно касалось только memory leak-ов и use-after-free, которые не эксплуатируемы с точки зрения безопасности.

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

В-третьих, я вообще не вижу в исследовании «показательной» части. Там написано «We submit the three patches», но где там написано, что с ними стало? Патчи были приняты? Отвергнуты? Исправлены?

в ядро Линукса можно внедрить все что твоей душе угодно.

так ничего в него не внедрили, начитался какой-то хни и уже делает выводы. Они проверили пройдут ли их говнопатчи ревью. Вот баг №1 из их статейки обнаружен благодаря kasan

https://github.com/torvalds/linux/commit/6ff7b060535e87c2ae14dd8548512abfdda528fb

но где там написано, что с ними стало? Патчи были приняты? Отвергнуты? Исправлены?

как только майнтайнер говорил «выглядит ок» признавались что на самом деле нет, писали от вымышленных имён, в ядро ничего не попало, никакими инструментами типа kasan не проверялось

но где там написано, что с ними стало? Патчи были приняты? Отвергнуты? Исправлены?

как только майнтайнер говорил «выглядит ок» признавались что на самом деле нет, писали от вымышленных имён, в ядро ничего не попало, никакими инструментами типа kasan не проверялось

А говорил ли он, что «выглядит ок»? Может мейнтейнер сразу сказал, что патч гавно, и все три патча были отвергнуты?

А говорил ли он, что «выглядит ок»? Может мейнтейнер сразу сказал, что патч гавно, и все три патча были отвергнуты?

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

Проблема — не в узком месте. Все знают, что код-ревью не даёт 100% гарантии. Тут они ничего нового не сказали.

мне кажется все еще прозаичней. Они просто не ожидали такой подляны от МАССАЧУСЕТСКОГО университета. Прислал бы патч МГУ из Росси они проверили все знаки препинания в комментах Деление дефакто на «своих» и «чужих» показало свою лучшую сторону

а кукаретики как всегда закудахтали «шерето»

дык это тру-линуксоиды с лора. Которые наверняка еще и скрины в галлерею постят

а для кого-то это открытие

Ну, лорошкольников мы в этой теме не рассматриваем за нерелеватностью.

Это исследование из университета Миннесоты.

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

Сабжевая проверка в армии выглядела бы примерно так

Аналогия не верная.

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

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

оно касалось только memory leak-ов и use-after-free, которые не эксплуатируемы с точки зрения безопасности.

Всё там прекрасно эксплуатируемо, если знать как. «Безопасность» это не только школо-«поиметь рута», но и обычный dos.

Исследователям много чего удавалось , на то они и исследователи

        // read status reg in order to clear pending irqs
-       sp8870_readreg(state, 0x200);
+       err = sp8870_readreg(state, 0x200);
+       if (err)
+               return err;

типичный говнопатч который ничего не исправляет
https://www.mail-archive.com/linux-media@vger.kernel.org/msg142381.html

In sp8870_set_frontend_parameters, the function sp8870_readreg may return an error when i2c_transfer fails. The fix checks for this error and returns upstream consistent with other invocations.

Signed-off-by: Aditya Pakki <pakki...@umn.edu>

Не просто «ничего не исправляет», а добавляет баг же?

Ведь функция sp8870_readreg() возвращает считанное значение статусного регистра. А там вполне может быть не ноль.

Можно было бы обсудить патч:

        // read status reg in order to clear pending irqs
-       sp8870_readreg(state, 0x200);
+       err = sp8870_readreg(state, 0x200);
+       if (err < 0)
+               return -EIO;

А в том виде это таки похоже на баг.

Не баг безопасности, просто баг в драйвере, из-за которого устройство может не работать.

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

Не просто «ничего не исправляет», а добавляет баг же?

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

Ведь функция sp8870_readreg() возвращает считанное значение статусного регистра. А там вполне может быть не ноль.

Аналогия не верная.

Очень даже верная.

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

«Стандартная проверка» не длится годами.

Она была бы «стандартной», если бы они сделали то, что написано в исследовании — отправили три патча (да фиг с ним, пусть даже 20 патчей) разной степени замаскированности в разные подсистемы ядра, и сделали бы вывод: какие мейнтейнеры более внимательны, посоветовали бы как улучшить ситуацию, дали бы свои инструменты для автоматического поиска таких багов...

Вместо этого они уже НЕСКОЛЬКО ЛЕТ засирают рассылки бажными патчами, отнимая время девелоперов. Какая «стандартная проверка» так делает?

Всё там прекрасно эксплуатируемо, если знать как. «Безопасность» это не только школо-«поиметь рута», но и обычный dos.

Э... попробуй-ка придумать как поэксплоитить хоть один из их примеров.