> Но цель же не в том, чтобы дрессировать апстрим принимать объёмные изменения.
> Цель — получить хорошо защищённое ядро.

Чтобы получить действительно хорошо защищённое ядро, в его код нужно вносить системные изменения, которые бывают довольно объёмными и/или инвазивными, иногда затрагивая весь код ядра. Например, REFCOUNT, CONSTIFY и, конечно же, RAP. Такие изменения на данный момент либо не принимаются вовсе, либо принимаются в урезанном виде и только так, без реальных перспектив расширения их области применения, хотя бы, до той, которая уже достигнута в grsec.

Есть и относительно небольшие имзменения, которые апстрим не принимает в принципе - потому что они ему не нравятся, буквально. Торвальдс, в частности, негативно высказывался в адрес реализации UDEREF для x86 (не x86_64) на базе механизма сегментации памяти. Та же судьба ожидает per-cpu PGD, необходимые для реализации UDEREF на x86_64, как и сам принцип ремаппинга пользовательских страниц при каждой смене контекста/режима: будет сказано, что это безумие в плане производительности, и зачем вообще это нужно, когда есть SMAP. И не будет никакого значения иметь ни то, что пользователь может отключить/не включать ненужные ему защиты (при сборке ядра или на этапе загрузки) или осознанно жертвовать производительностью (как многие пользователи grsec), ни то, что большая часть процессоров на сегодняший день не имеет поддержки SMAP, ни то, что SMAP и SMEP довольно просто и перманентно могут быть отключены в процессе эксплуатации уязвимостей, как уже не раз было показано.

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

Кстати, вспомните последние наиболее серьёзные уязвимости: CVE-2014-3153 и CVE-2016-5195. Grsecurity никак не уменьшает сложность их эксплуатации. Понимаете, что это значит? В грубом приближении: что информация об уязвимостях, против которых, если можно так выразиться, бессилен даже grsec, появляется в публичном доступе каждые 2 года. А о скольких подобных уязвимостях мы ничего не знаем и, может быть, не узнаем? Сколько времени они существуют в коде до момента их устранения (иногда больше 10 лет)? А атаки на микроархитектуру? В частности, на кэши последнего уровня, которым на данный момент даже grsec не пытается ничего противопоставить?

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

> И не настолько важно, как мы к нему придём.

Опять же, это очень большое допущение: что мы к нему придём, а также что апстрим собирается идти к нему вместе с нами. Представим, что лет через 5-15 по уровню защищённости апстрим догонит сегодняшний grsec. Давайте посмотрим на это с другой точки зрения: а чем в это время будет заниматься атакующая сторона? Сидеть на месте и ждать, пока в линуксе соизволят научиться хорошо защищаться хотя бы от атак по векторам и методикам 15-летней давности от настоящего времени?

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

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

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

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

>> Мне кажется, вы исходите из предпосылки об искренности всех участников. В том числе об искренних и неустранимых заблуждениях.
> Я не исхожу из неё, лишь допускаю такой вариант тоже. Это логичное
> допущение.

Это допущение не только нелогично, но уже опровергнуто самим выбором подхода к освещению ситуации со стороны LF и других ангажированных участников.

1. Есть специфика области безопасности (не только информационной), которая обуславливает неуместность любого оптимизма в оценках, даже обоснованного: the worst case is what matters.

2. Есть стандарты журналистики, этически и методически несовместимые с рекламой.

3. Есть некоторое помнимание ситуации внутри группы, у некоторых её членов (то же Кэйс Кук).

При всём при том, что мы имеем? Неуместный оптимизм, рекламные материалы вместо журналистики и заведомо неполное освещение ситуации, невзирая на наличие внутренних источников более полной и объективной информации о ней. Искренность и непредвзятость там и не ночевали. :) И вовсе не по недоразумению, а совершенно закономерно.

> Ведь если участники не работают над устранением проблемы, то либо
> они не видят проблему, либо не считают её проблемой, что в
> общем-то то же самое.

...или не воспринимают проблему, как свою. ;) Как говорится, проблемы негров шерифа не волнуют.

> А если бы они работали над устранением проблемы и стремились улучшить ситуацию,
> то зачем grsec-овцам закрывать патчи?

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

>> Кэйс Кук, глава KSPP, прекрасно осведомлён о происходящем, не поддерживает пиар со стороны LF ни по форме, ни по содержанию. Осознаёт [...] недостатки текущего подхода [...] (и он, как ему кажется, над этим работает).
> Но раз Grsecurity закрыли патчи, то для них этого было недостаточно, они
> хотели большего. Упоминания своих заслуг в публикациях LF/KSPP, возможно?

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

> Вроде Кук как раз упоминал в своих коммитах grsec, и даже указывал
> отличие своих патчей от патчей grsec. То есть открыто описывать надо
> было не Куку, а тем, кто пишет обзоры его работ.

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

> Или вы полагаете, что LF/RedHat намеренно умалчивали о Grsecurity с той
> целью, чтобы разозлить их и вынудить их уйти с арены? Тогда,
> выходит, LF победили?

Я вообще несколько не о том говорил. Но точно знаю, что о Grsecurity намеренно умалчивают как о конкуренте или, если угодно, как о источнике превосходящих технологий и решений, которые Red Hat и другие члены LF не могут или не хотят предложить своим клиентам.

> Не просто не политизировать, они в passing_the_baton_faq включили пункт "Why are you
> REALLY doing this?", но ни слова в нём не написали про
> введение сообщества в заблуждение или недобросовестную конкуренцию.

Это я и называю "не политизировать".

> Возможно, мосты и не сожжены, но они уже горят. В официальном анонсе

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

> произошло, но что ещё более важно, не знают что делать, чтобы это изменить.

Не вести себя по-скотски, для начала. Вы обратили внимание, какую реакцию встречают альтернативные мнения, вроде того, что я стараюсь донести здесь? Они присутствуют в информационном пространстве, но мало, кому интересны, мягко говоря.

> Да, пострадает в первую очередь сообщество.

Похоже, мне так и не удалось донести мысль... Сообщество уже страдает, очень давно и независимо о того, существует ли Grsecurity и что с ним происходит.

> Но пострадают и Grsecurity, которым это сообщество создавало рекламу.

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

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

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

Они были слабы, пока не позиционировали себя преимущественно или исключительно как бизнес, поскольку для потенциальных клиентов выглядили как группка энтузиастов, не способных обеспечить себя за счёт коммерциализации результатов своей работы. И закономерно, что в качестве поставщика продукта и услуг они были интересны только малому числу специфически осведомлённых компаний.

> Более защищённое ядро и может быть этим результатом — и маркетинговым и
> реальным. И в этом заинтересованность есть. Должна быть. Её не может
> не быть. Взгляды могут расходиться лишь в способах достижения этого результата.

Ну что ж. В любом случае, к уже сказанному мне по большему счёту добавить нечего.

> Тогда нужны статьи, наверное. Они уже встречаются, но их мало. Есть неплохой
> обзор в статье про RAP где-то на сайте grsec.

Нужны не отдельные статьи, а системные изменения в подходе, в том числе по части информационного сопровождения. Корректировка ценностей, целей и средств.

> Да и та же презентация Кука, на которую вы скидывали ссылку, которая "killing
> bugs is nice, but killing bug classes is better", она ведь тоже об этом.

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

> По идее, это как раз и есть организации вроде FSF и LF,
> а также своего рода СМИ вроде LWN и phoronix-а.

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

>> Плюс ещё сильнее введённое в заблуждение сообщество.
> На счёт сообщества, кстати, интересный вопрос. Пусть LF/KSPP не особо рекламировали то,
> что их работа основана на патчах grsec, но действительно ли сообщество

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

> об этом не знало? Может это было настолько очевидно, что в рекламе не нуждалось?

Это сообщество до сих пор не в курсе, что PaX и Grsecurity являются первоисточниками большинства механизмов защиты, известных и используемых на сегодняшний день. Эти люди подозревают проект в шкурности интересов, не отдавая себе отчёт даже в том, что на одном только патентовании и последующей продаже патентов разработчики grsec давно могли и всё ещё могут сколотить себе состояние. А вы предполагаете, что сообщество может быть в курсе, откуда KSPP черпает идеи и код. :) Ах, если бы...

> Просто любопытно, какая у них основная работа?

Я никогда особо не интересовался и не уточнял у них, но в паблике кое-что есть:

http://phrack.org/issues/66/2.html - PaX Team, по данным на 2009 год:

|=---=[ Your current life in a paragraph

    Working on some PHP/.net/js stuff for a SaaS startup, and generally
    tired of everything security related. Fortunately there's life beyond
    that :).

https://github.com/brad-accuvant/cuckoo-modified , https://www.optiv.com/ - одно из последних мест работы Брэда, 2015 год.