Comments 16
Он все-таки извинился:
lwn.net/Articles/764901
В любом случае, все его замечания по коду я устранил.
Кейс Кук снова пошлет pull request в грядущий релиз.
Поздравляю с результатами! Это шаги в правильном направлении.
Добрый вечер, товарищ эксперт.
Ваше начинание может и хорошо, но то, что вы пишете в переписке с человеком, который ответственен за то, что он принимает в ядро (которое, к слову, крутится на миллионах компьютеров) это, извините, пц.
Спасибо большое, я уже 6 лет разрабатываю ядро и знаю, кто такой Линус.
А что же именно такого я ему написал?
Вам указали на ошибки, вам сказали что код ужасен, вы прекрасно осведомлены, что Линус не стесняется в выражениях.
Все недостатки, на которые мне указали Линус Торвальдс, Инго Молнар, Кейс Кук, Марк Рутланд, Питер Зийлстра и еще ряд людей, я устранил в течение полутора лет, пока работал над STACKLEAK. В этом и заключается итеративная работа в LKML (аналогично с другими открытыми проектами).
Нет, вы будете кричать о том, как Линус не прав, будете на конференции
Ах, так это я кричу? Да я предельно корректен, уважаемый.
рассказывать как у вас пригорело от того, какой Линус плохой. Да блин, у вас на слайдах написано, что после первых замечаний вы откодестайлили код, убрали магические переменные, прекратили делать oops в kernel space, откомментировали код и проч.
Вы рассуждаете, хотя не смотрели патчи. Вы даже не видели changelog, гарантирую.
Конкретные претензии Линуса к 9 версии были в том, что код очистки стека написан на ассемблере. А во время pull-request 14 версии он поменял правила игры и запретил BUG_ON() во всех патчах по kernel hardening. Вы не видите реакции Кейса Кука?
Вы что? Вы послали разработчикам ядра патч, который:
- Содержит магические константы
- Валит ядро
- Недокументирован
Дорогой эксперт, всё, что вы перечислили, содержится в изначальном коде grsecurity. Смотрите лучше патчи, а потом комментируйте.
Да вас еще на входе должно было отстрелить. То есть вам настолько было все равно, что вы даже не почитали правила отправки патчей в ядро.
После первого раза Линус вам сказал, что подход, который вы используете неверен, что он против такого подхода, даже чинить дальше бессмысленно, потому что сам базовый подход некуда не годен.
А я и еще очень много людей считают, что изначальный подход по очистке остаточной информации в ядерном стеке очень даже хорош. Что дальше?
Но нет, вы покрасили стены и послали его второй раз без изменения базовой концепции. Получили ожог седалища. А теперь виноват Линус.
Попытка номер 3. Посмотрите код, если можете. А потом давайте авторитетную оценку. Лучше не сюда, а в LKML, пожалуйста.
Вижу, что патчи или хотя бы список изменений по версиям вы решили не смотреть.
Ну ладно.
Проблема не в том, за сколько вы их исправили, а то что вы тратили время разработчиков из рассылки (в т.ч. Линуса) на вообще никак не соответствующий даже просто правилам приличия код (magic numbers, нет комментариев, валит ядро).А после этого пошли жаловаться на презентации что у вас Burnt.
То, что вы пишете, ложно. Зачем-то вы выдумываете.
В разработке ПО есть принцип RERO (Release early, release often). Следуя ему первые версии STACKLEAK я посылал с тэгом RFC узкому кругу людей. А в cover letter были обозначены TODO пункты. Так делают все, кто работает над крупными задачами в ядре Linux.
По мере того, как серия патчей становилась все более качественной, я понемногу расширял список получателей в LKML.
Линус впервые увидел STACKLEAK на 9 версии патч-серии (в марте). По мнению Кейса Кука (мэйнтейнер gcc-плагинов) и некоторых разработчиков x86 этот код уже вполне соответствовал критериям приема в mainline. Линус, кстати, отдельно выразил недовольство тем, что STACKLEAK посылался слишком узкому кругу разработчиков. Но основным раздражающим фактором для него была очистка стека, написанная на ассемблере (около 100 строк). Мне стоило большого труда в 10 версии переписать этот ассемблер на C так, чтобы компилятор выдавал бинарь, который очень похож на рукописный ассемблер. Однако это дало возможность Лоре Эббот в дальнейшем без проблем портировать STACKLEAK на arm64.
Теперь по поводу BUG_ON(). Это assertion в ядре Linux, который вызывается в экстренных случаях, например когда мы обнаружили порчу памяти либо невосстановимую ошибку во внутренних структурах ядра. Если в командной строке ядра не выставлен panic_on_warn, BUG_ON() в системном вызове приводит к остановке пользовательского процесса, от которого в данный момент работало ядро.
В случае STACKLEAK BUG_ON() вызывался при порче lowest_stack и при блокировке атаки Stack Clash. Это правильно, потому что ядро должно прерывать порчу памяти или эксплойт как можно скорее.
Но у Линуса и KSPP давнишний спор по поводу BUG_ON(). Я знаю, что Кейс Кук снова будет обсуждать с Линусом этот вопрос и искать компромиссы, когда тот вернется из своего отпуска.
Одним из путей, кстати, может быть введение SECURITY_BUG_ON(), который дает oops при включении определенной config-опции ядра. Это было бы аналогично существующей опции CONFIG_BUG_ON_DATA_CORRUPTION.
А на счет "жалоб", как вы это назвали, — в докладе я обозначил только факты, без оценок.
Быть несогласным — это нормально. Приводить технические аргументы — это прекрасно. Именно поэтому ядро Linux и его сообщество живет — мы спорим и находим компромиссы.
Вот бы ещё всё остальное из PaX и GrSecurity получить на текущих ядрах… minipli остановился на 4.9.74, ниасилив слияние с патчами Meltdown/Spectre. :( Персональных лицензий GrSec не продают. Сидеть вечно на 4.9.74 тоже не вариант. Всё плохо, в общем.
А что сказали на это grsercurity-товарищи? Особенно в контексте, «какое было, какое стало».
PaX Team промолчал, а Брэд как всегда в своем стиле — рафинированный троллинг и прессинг.
Раньше я переживал от этого, а сейчас уже даже занимательно.
Так вот LWN выпустил статью про STACKLEAK после Linux Security Summit: https://lwn.net/Articles/764325/
После этого Брэд сразу атаковал, я ответил и понеслась: https://lwn.net/Articles/764685/
Он громко ушел с LWN некоторое время назад, поэтому полемика получилась странная: он пишет в твиттере и своем блоге, я отвечаю в LWN.
В любом случае моя цель была вытянуть из него побольше информации. Мне кажется, это в целом получилось.
git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2d6bb6adb714b133db92ccd4bfc9c20f75f71f3f
Поддерживаются архитектуры x86_64, x86_32 и arm64.
Кроме того, закончены работы по устранению массивов переменной длины из кода ядра Linux. В версии ядра 4.20 включено предупреждение "-Wvla" компилятора gcc: lkml.org/lkml/2018/10/28/189
Это здорово, но в целом ситуация не очень радует — ушло больше полугода и море энтузиазма чтобы протащить в ядро маленький кусочек того, что неплохо защищало наши сервера очень много лет. Такими темпами прежний уровень защиты мы получим примерно никогда. А частным лицам и мелкому бизнесу GrSecurity не продают, так что даже за деньги проблему сейчас решить невозможно. :(
И да, grsecurity очень придирчиво выбирают, кому продать свою подписку. Плюс, по моим сведениям, цена этой подписки такая, что ни частные лица, ни мелкий бизнес ее не потянут (конкретные цифры не буду говорить).
И вместе с тем предлагаю посмотреть шире. Работа над STACKLEAK все-таки завершилась успехом и создала еще один хороший прецедент. Да, механизмы обеспечения безопасности не в приоритете для Линуса и мэйнтейнеров, но мы видим, как наши патчи заходят в ядро под config-опциями. Эти опции включаем мы, их начинают включать дистрибутивы. Работа идет, давайте работать!
Как STACKLEAK улучшает безопасность ядра Linux