[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