>> К примеру попытка создать свой аналог LSM, вместо того что бы брать
>> / адаптировать готовую инфраструктуру.
>> Сомнительное удовольствие как по мне, увеличивающее размер изменений.
> Почему и зачем это сделано, можно прочитать здесь: https://www.grsecurity.net/lsm.php Так все пишут - "нас старое не устраивает" "долой диктат - будем жить по новому".
Можно много чего писать, но факт остается фактом - дублирование инфраструктуры - никого до добра не доводило. Ну и странно было бы потом обсуждать "а чего не включают в ядро" когда сами разработчики положили болт и самоустранились.
>> Сомнительное переименование atomic / atomic_unchecked, увеличение патча без толку. Теже
> В каком смысле, переименование? У atomic_t и atomic_unchecked_t разная семантика и соответствующие
> наборы функций операций, с проверками на переполнение и без них. Чуть
> подробнее об этом можно прочитать здесь: https://forums.grsecurity.net/viewtopic.php?f=3&t=2750#p11162
Фактически весь atomic_t был переименован в atomic_uncheked и дальше применяются все проверки.
Теперь задумайтесь что мешало использовать инверсию. Ввести тип atomic_checked .. а в atomic_t добавить все проверки которые сделаны внутри atomic_unchecked. Да ничего - кроме вкуса, а это серьезно уменьшит патч и автоматом занесет весь код в разряд не проверенных.
> "заводится тип" - это вы про refcount_t? Он-то как раз и есть
> велосипед с квадратными колёсами, снижающий производительность: https://lwn.net/Articles/718275/
о типах atomic_t / atomic_unchecked.
> Помимо самой заметки, стоит обратить внимание на два последних комментария от zyzzyva
> и PaX Team.
>> которые просто лишние, зато влияют на время инспекций.
> Дело вкуса. Ляпом это назвать никак нельзя.
Любое увеличение размера изменений без добавления функциональности - увеличивает вероятность ошибки. И с этим надо считаться. Если для вас это дело в куса...
>> @@ -258,19 +259,19 @@ static ssize_t process_vm_rw_core(pid_t pid, const struct iovec *lvec,
>> + return -ENOSYS; // PaX: until properly audited
> Это соответствует моим ожиданиям как пользователя патча, с тем уточнением, что мои
> ядра вообще собраны без поддержки process_vm_*. :) То есть, тоже субъективно.
> Bikeshedding в любом случае. Сравнивать подобные якобы "ляпы" с серьёзными изъянами
> в результатах работы KSPP - совершенно некорректно.
Вообще там сначала мы пытаемся что-то почтить, потом просто поставили return в начале функции. Спрашивается зачем те изменения что есть? Начали и бросили?
>> -static struct vfsmount *shm_mnt;
>> +struct vfsmount *shm_mnt;
>> Опа.. теперь любой полазив в system.map может добраться сюда..
> А пара десятков тысяч других подобных определений в коде ядра вас не
> смущают? :)
Смущают. Но эти изменения писали люди без оглядки на безопасность.
>[оверквотинг удален]
>> + if (atomic_read(*t->fs->users) != 1)
>> return -EINVAL;
>>
>> если открыть стандарт - reading always atomic if integer type size less or same than long.
>> так что эта замена вызовет только лишние LOCK по шине и тормоза.
>> Так и еще замены подобные есть.
> Вы это серьёзно или подкалываете? Атомарность чтения как операции не имеет совершенно
> никакого отношения к валидности значения при его конкурентном чтении и записи
> из нескольких параллельных потоков. Согласно стандарту, поведение в таких случаях не
> определено. Зачем бы тогда вообще atomic_read нужен был?
Это надо спросить у тех кто делал такую замену. Общий локинг вокруг fs->users не менялся, но вот зачем-то туда запихали atomic_. Возможно было проще контролировать переполнения так, возможно какие-то еще идеи. Но ...
>> вообщем оно хорошо, но надо быть честным - есть ляпы и там.
> Наверное, всё-таки действительно надо быть честным и признать, что если смысл чего-либо
> неясен на первый взгляд, это ещё не значит, что его нет?
> :)
Есть вещи которых можно добиться слегка иначе, проще и не увеличивая размер изменений. Это таки ляпы.
