[devel] зачем вообще может быть нужен initrd при загрузке с локального носителя

Alexey V. Vissarionov gremlin на altlinux.org
Чт Апр 12 11:44:27 MSK 2018


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
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : signature.asc
Тип     : application/pgp-signature
Размер  : 801 байтов
Описание: отсутствует
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20180412/23c7a3c1/attachment.bin>


Подробная информация о списке рассылки Devel