Проверка патчей (из списка в lkml.org/lkml/2021/4/21/454) типа «Fix potential memory leak», «fix potential double-free», «Fix several reference count leaks», «Fix a double-unlock issue», или «Fix a potential NULL pointer», «Avoid potential use after free» обычно требует очень подробного разбирательства, т.к. работа с данными может быть не локализована в одном модуле/подсистеме, растянута по времени и иметь множество путей обработки.
Если такими патчами прицельно «заваливать» мейнтенера, то он, с большой вероятностью, на очередном «сломается» и начнет больше доверять, чем проверять. Имеет ли практический смысл этот простой психологический приём проверять на практике? Не уверен.
Патчи вида «fix a potential missing-check bug», «Check the return value», «replace BUG_ON with error handling code» и «fix incomplete error-handling» могут иметь двойное дно, так как на первый взгляд проверяются легко (да, действительно, не проверили возвращаемое значение, нужно добавить проверку), но в реальности могут оказаться не нужными (например, если возвращаемое значение не важно в текущем контексте или ситуация не может возникнуть в принципе). Результат принятия таких патчей — добавление не нужных проверок и, как результат, снижение производительности (на что, кстати, жалуются уже несколько лет) и увеличения размера кода ядра.
Фактически это вредительство, никакого отношения к улучшению безопасности системы не имеющее. Предполагаю, что такие патчи вносились экспериментаторами с целью повышения своего «рейтинга» (притупления бдительности) и облегчения «продвижения» своих целевых (вредоносных) патчей, но побочный эффект в виде снижения качества кода ядра от этого никуда не исчезает.
И, наконец, патчи вида «Remove redundant check», «remove unnecessary assertion», «replace BUG_ON with recovery code», «Reduce the severity of logging» требуют в первую очередь проверки с точки зрения безопасности. Говоря честно, не все (точнее — не многие) мейнтейнеры являются специалистами, квалификации которых достаточно для проверки таких патчей (исключая тривиальные случаи). С большой вероятностью, именно такие патчи и содержат «целевой» код, который требовалось внедрить.
Думаю, всем очевидно, что основная ценность представленной «научной работы» не столько в доказательстве возможности внедрения вредоносного кода в OpenSource проекты (этим давно занимаются заинтересованные организации и частные лица), сколько в дискредитации выстроенной за много лет системы разработки ядра Linux в частности и OpenSource проектов вообще (так как они часто построены по такому же принципу).
Если такими патчами прицельно «заваливать» мейнтенера, то он, с большой вероятностью, на очередном «сломается» и начнет больше доверять, чем проверять. Имеет ли практический смысл этот простой психологический приём проверять на практике? Не уверен.
Патчи вида «fix a potential missing-check bug», «Check the return value», «replace BUG_ON with error handling code» и «fix incomplete error-handling» могут иметь двойное дно, так как на первый взгляд проверяются легко (да, действительно, не проверили возвращаемое значение, нужно добавить проверку), но в реальности могут оказаться не нужными (например, если возвращаемое значение не важно в текущем контексте или ситуация не может возникнуть в принципе). Результат принятия таких патчей — добавление не нужных проверок и, как результат, снижение производительности (на что, кстати, жалуются уже несколько лет) и увеличения размера кода ядра.
Фактически это вредительство, никакого отношения к улучшению безопасности системы не имеющее. Предполагаю, что такие патчи вносились экспериментаторами с целью повышения своего «рейтинга» (притупления бдительности) и облегчения «продвижения» своих целевых (вредоносных) патчей, но побочный эффект в виде снижения качества кода ядра от этого никуда не исчезает.
И, наконец, патчи вида «Remove redundant check», «remove unnecessary assertion», «replace BUG_ON with recovery code», «Reduce the severity of logging» требуют в первую очередь проверки с точки зрения безопасности. Говоря честно, не все (точнее — не многие) мейнтейнеры являются специалистами, квалификации которых достаточно для проверки таких патчей (исключая тривиальные случаи). С большой вероятностью, именно такие патчи и содержат «целевой» код, который требовалось внедрить.
Думаю, всем очевидно, что основная ценность представленной «научной работы» не столько в доказательстве возможности внедрения вредоносного кода в OpenSource проекты (этим давно занимаются заинтересованные организации и частные лица), сколько в дискредитации выстроенной за много лет системы разработки ядра Linux в частности и OpenSource проектов вообще (так как они часто построены по такому же принципу).