>> Почему и зачем это сделано, можно прочитать здесь: https://www.grsecurity.net/lsm.php
> Так все пишут - "нас старое не устраивает" "долой диктат - будем
> жить по новому".Это неконструктивный разговор. Всю аргументацию по ссылке вы свели к "нас не устраивает".
> Можно много чего писать, но факт остается фактом - дублирование инфраструктуры -
Факт в том, что существующая инфраструктура не предоставляет всю необходимую функциональность, не позволяет использовать RBAC совместно с другими LSM и своим присутствием в ядре создаёт дополнительные риски безопасности.
> никого до добра не доводило. Ну и странно было бы потом
> обсуждать "а чего не включают в ядро" когда сами разработчики положили
> болт и самоустранились.
Разработчики Grsecurity никогда не пытались и не изъявляли желания включить свой патч в апстрим.
> Фактически весь atomic_t был переименован в atomic_uncheked и дальше применяются все проверки.
Фактически - в дополнение к существующему типу добавили ещё один. А не переименовали, как вы упорно утверждаете. atomic_t в большинстве случаев используется для подсчёта ссылок и переполняться не должен, а atomic_unchecked_t и аналогами помечены немногочисленные остальные случаи.
> Теперь задумайтесь что мешало использовать инверсию. Ввести тип atomic_checked .. а
> в atomic_t добавить все проверки которые сделаны внутри atomic_unchecked. Да ничего
> - кроме вкуса, а это серьезно уменьшит патч и автоматом занесет
> весь код в разряд не проверенных.
Проверки добавлены не "внутри atomic_unchecked", а для atomic_t. Сделано ровно то, о чём вы говорите.
> Любое увеличение размера изменений без добавления функциональности - увеличивает вероятность
> ошибки. И с этим надо считаться. Если для вас это дело вкуса...
Всё это не более, чем максимализм и казуистика. Во-первых, пример ничтожный во всех смыслах. Во-вторых, изначальный код имел больший объём на то же количество логики - против такой дополнительной сложности у вас почему-то возражений не возникло.
> Вообще там сначала мы пытаемся что-то почтить, потом просто поставили return в
> начале функции. Спрашивается зачем те изменения что есть? Начали и бросили?
Затем, чтобы продолжить в следующий раз, когда более приоритетные задачи будут решены.
> Смущают. Но эти изменения писали люди без оглядки на безопасность.
Какие именно, эти? Приведённые вами, из патча Grsecurity? Если да, то они на безопасность никак негативно не влияют. И ляпами не являются, поскольку были внесены по осознанной надобности.
> Это надо спросить у тех кто делал такую замену. Общий локинг вокруг
> fs->users не менялся, но вот зачем-то туда запихали atomic_. Возможно было
> проще контролировать переполнения так, возможно какие-то еще идеи. Но ...
Очевидно, что users используется в качестве счётчиков ссылок и должен быть защищён от переполнений. На производительность это не виляет практически никак.
> Есть вещи которых можно добиться слегка иначе, проще и не увеличивая размер
> изменений. Это таки ляпы.
Вам, конечно же, виднее, как проще и лучше добиваться того, что на высочайшем профессиональном уровне в течение многих лет делают другие. ;)
