On 2018-04-11 21:24:18 +0300, Dmitry V. Levin wrote: >>>> Коллеги, а вот кто может внятно объяснить, зачем вообще >>>> может быть нужен initrd при загрузке с локального носителя >>>> (непосредственно подключенного к компутеру)? >>> Множество причин, тысячи их. >> Доброго сэра, конечно же, не затруднит назвать хотя бы десяток >> причин из этих тысяч? > Даже при загрузке с локального носителя есть штатные > конфигурации, в которых ядро само не может смонтировать rootfs и > запустить оттуда init, например: > - драйвер локального носителя не вкомпилирован в ядро; > - драйвер файловой системы rootfs не вкомпилирован в ядро; Дим, ну самому-то не смешно? Локальный носитель в 90% случаев (у меня, конечно, выборка весьма средненькая, даже пары тысяч хостов не наберется) - либо жесткий диск на platform AHCI SATA, либо USB mass storage, подключенный к одному из четырех типов УПШ-хостов: OHCI, UHCI, EHCI или недавно появившемуся XHCI для USB3. Размер соответствующих ядерных модулей составляет 417+75 == 492 килобайта. Размер ядерного модуля ext4 (который поддерживает ext2 и ext3) - 447 килобайтов. Корневой раздел с файловой системой, отличной от ext[34], мне встретился ровно один раз, и его история, по словам тамошнего админа, была такова: "приехал новый сервер, пока было не срочно - решил поэкспериментировать, а потом гавкнулся один из боевых серверов и нужно было заменить его в течение %u минут - вот с тех пор и трудится" (надеюсь, от замены специального технического термина на эвфемизм "гавкнулся" смысл цитаты не сильно исказился). Вышеприведенные цифири я получил в процессе сборки ядра 4.16 (да, есть и более свежее, но это уже было развернуто у меня в ~/tmp для генерации патча именно под эту версию и тестовой сборки). Вот еще одна цифирь: gremlin@evil:~/tmp/linux-4.16 > strip vmlinux.o gremlin@evil:~/tmp/linux-4.16 > lh vmlinux.o -rw------- 1 gremlin users 36M апр 12 10:38 vmlinux.o gremlin@evil:~/tmp/linux-4.16 > lh arch/x86/boot/bzImage -rw------- 1 gremlin users 12M апр 12 10:29 arch/x86/boot/bzImage Ну да, цифирей тут две, но они отражают два важных свойства ядра - сколько оно займет в памяти (первая, 36 мегабайтов) и сколько места ему понадобится в корневом разделе (вторая, 12 мегабайтов). Памяти, понятное дело, в процессе работы потребуется где-то в полтора раза больше (полсотни мегабайтов), но тут мне хочется снова процитировать Б.Л.Пастернака: "Какое, милые, у нас тысячелетье на дворе?" - благо, ответом на вопрос поэта вполне может служить `head -1 /proc/meminfo` Так что даже совместно эти два примера с трудом дотягивают даже до одной причины из обещанных тысяч (или из запрошенного десятка). > - требуются нетривиальные действия для подготовки rootfs к > монтированию, не связанные с загрузкой модулей ядра, например, > расшифровка устройства с помощью ключа, тем или иным способом > полученного от оператора загрузки во время загрузки. Вот это уже чуть более интересный пример, а решаемая задача вполне может считаться типовой. Да, зашифрованные разделы бывают - я лично рекомендую всем защищать как минимум /home; уточню, что это особенно актуально для серверов, ибо позволяет "взлететь" с незашифрованного корневого раздела, где кроме ~root/.ssh/authorized_keys в принципе нет ничего интересного, да и его содержимое никакой практической ценности не представляет. Единственный риск, который сохраняется при таком подходе к защите - компрометация ОС в незашифрованном корневом разделе, но сделать это незаметно крайне сложно и очень дорого, ущерб минимален (равен стоимости рабочего времени, потраченного на установку чистой системы), а вероятность исчезающе мала, что очевидным образом помещает этот риск в левый верхний угол оценочной таблицы (low severity, low probability). Для рабочих станций (особенно ноутбуков, которые могут быть украдены), действительно, можно использовать описанный тобой способ, но у него есть существенный недостаток: он требует загрузки с внешнего носителя (иначе ничем принципиально не отличается от варианта с незашифрованным корнем), что порождает два дополнительных требования по защите 1. флешки - от утраты традиционным способом или опять же компрометации; 2. компутера - от загрузки с чужой флешки. В общем случае вариант с криптозащитой /home является предпочтительным, поэтому я остановил свой выбор именно на нем. Что и остальным советую. Но пример действительно неплох, так что вполне может считаться второй причиной из обещанных тысяч. -- Alexey V. Vissarionov gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net