Как бы grub-ом загрузиться с запароленого hdd? (и другие вопросы про груб)

грузится груб, запрашивает пароль, разблокирует им другой винчестер, после чего передает ему загрузку.

Это имеет какой-то смысл без тотального шифрования данных?

конечно. Пароль же не на груб, а на винчестер.

Debian Encrypted Partitions with LUKS
HOWTO: Unlock a LUKS encrypted root partition via ssh
Unlocking a LUKS encrypted root partition remotely via SSH

Не, ну это криптование партишенов. Это не то. У винчестеров есть функция установки пароля и разлочки. Хотелось через них. фишка в том, что на таком винте может быть совершенно любые ос. При загрузке ввел пароль - и дальше работаешь как обычно.

Это фича бивиса, а не загрузчика. Он не умеет такое и никогда не будет уметь, если только не сделают «принципиально новые©®™» винты. Единственная возможность сделать это сейчас - криптованием раздела(-ов).

Более того, это делается низкоуровневой ATA-командой, и BIOS знает какому винту её дать. GRUB же не знает ничего ниже функции INT13H и не может знать, поэтому ATA-команду на разлочку винта по паролю дать не может, а пользовательской программной BIOS-функции разлочки пароля по-видимому нет, так что GRUB тут да, не поможет. К тому же, GRUB не знает, какому винту из подключённых на каналы давать ATA-команду для разлочки паролем, он даже не знает, ATA винт или SCSI (в последнем случае, очевидно, такой команды IMHO нет).

ясно.

Не, ну это уже конечно все отмазки. Чтобы проблему «не знает кому» решать, существуют конфиг-файлы. Про биос вообще детский лепет - ведь никто не мешает грубу сделать нужное int.

вобщем ясно. Нет так нет.

Более того, это делается низкоуровневой ATA-командой

я что-то не понял: а если не дать такой команды, а просто тупо прочитать винт, он что, ничего не отдаст? Можно ссылку на чудо-команду?

Я это к тому, что науке могут быть неизвестны пользовательские функции BIOS, принимающие произвольные ATA-команды для физических дисков 80h, 81h, ... . Насколько помню, для работы с жёсткими дисками есть BIOS-функции в рамках программного прерывания int 13h. В ней есть только запись, чтение и т п — базовые функции ввода-вывода, что и означает аббревиатура BIOS. Для более продвинутых вещей нужен прямой доступ к железу. GRUB — такая вещь, которая работает и для SCSI, и для ATA и для USB, — как в среде BIOS, так и в среде UEFI. И очевидно, в ней нет своих дров, которые сканируют шину PCI и делают ввод-вывод на уровне портов ввода-вывода и адресов памяти ввода-вывода.

http://en.wikipedia.org/wiki/INT_13H — вот тут не ищется по слову password.

Может, в среде UEFI более глубокое погружение в железо — врать не буду, но в среде BIOS — нет, насколько мне известно, каких-то волшебных недекларированных возможностей.

Или Вы знаете другие int для работы с жестким диском, кроме 13h? Было бы интересно взглянуть.

На то она и защита паролем на жёсткий диск, чтоб не знающий пароль не прочёл ни один из его секторов.

Для случая PATA описано на английской Википедии http://en.wikipedia.org/wiki/Parallel_ATA#HDD_passwords_and_security

Поскольку программный интерфейс один и тот же, и для SATA такого описания нет, то наверняка для SATA тоже самое.

для работы с жёсткими дисками есть BIOS-функции в рамках программного прерывания int 13h.

насколько я знаю, так было только во времена MS-DOS.

А теперь ОС САМА рулит железом, на самом низком уровне, и ей глубоко наплевать, что там у неё в BIOS. Мало того, она ещё и подменяет int из BIOS на свои.

А grub, насколько я знаю, делает точно также.

Т.е. вы можете смело рулить железом напрямую, достаточно лишь написать модуль для Linux, или драйвер для венды. Вроде как и для grub можно модули делать.

Хотя я и не вдавался особо.

Для случая PATA описано на английской Википедии http://en.wikipedia.org/wiki/Parallel_ATA#HDD_passwords_and_security

а, точно, помню я про эту ерунду:

Она отлично снимается, см. посл параграф:

While the ATA disk lock is intended to be impossible to defeat without a valid password, there are workarounds to unlock a drive. Many data recovery companies offer unlocking services,[25] so while the disk lock will deter a casual attacker, it is not secure against a qualified adversary.

IRL можно нагуглить программу разлочки нужного диска. И из-за этого, никто не использует данный способ. Вот шифрование куда как более стойкое(конечно при наличии очень многих условий).

Вроде как и для grub можно модули делать.

Нельзя, т.к. их нельзя будет использовать: чтобы их загрузить, уже должен быть доступен диск, на котором они лежат, и которого они обслуживают.

И поэтому фраза «другой винчестер» в вопросе была не случайна.

Нет, ну серьезно: модули, как и сам груб могут быть на загрузочном, а заблокирован может быть другой винт.

Я имел в виду то, что всё же по умолчанию, без самописных модулей, GRUB работает через BIOS, откуда и нумерация (hd0,0) (hd1,0) в его конфигах — которые, кстати, тоже читаются средствами BIOS.

Файлы читаются с флоппи, жёсткого диска или CD средствами BIOS со всеми вытекающими ограничениями и неприятностями типа путаницей со способом трансляции адресов блоков и нумерацией дисков.

Имя устройства заключается в круглые скобки и начинается с указания типа устройства (fd, hd, cd, nd) за которым идёт номер устройства. Устройства нумеруются с нуля, порядок определяется BIOS (в частности, ATA и SCSI диски не различаются).

http://www.bog.pp.ru/work/grub.html

Вот такое

http://ru.wikibooks.org/wiki/Grub_2

menuentry «windooz»{

search -u AC9C75E59C75AA8A -s

chainloader +1

}

работает также через BIOS. Поэтому я посоветовал бы Вам подумать в таком направлении:

• загружается Ваш модуль GRUB
• разлочивает диск, который еще каким-то образом и находит (либо это указывается вручную в параметрах вызова этого модуля)
• перехватывает прерывание int 13h — так, чтобы GRUB смог увидеть и подхватить свежеразлоченный диск для продолжения загрузки
• потом надо будет убедиться, что GRUB не надо пинать, и он не кеширует набор дисков, т.е. динамически опрашивает BIOS на предмет наличия того или иного hd — в противном случае, боюсь, придётся переписывать GRUB с нуля )) либо делать глубокий рефакторинг. Либо в API GRUB найти вызов для перечитывания списка устройств.

Нельзя, т.к. их нельзя будет использовать: чтобы их загрузить, уже должен быть доступен диск, на котором они лежат, и которого они обслуживают.

подумай, каким мистическим образом у меня ядро загружает модуль ext4, на котором у меня /boot/? ;)

Файлы читаются с флоппи, жёсткого диска или CD средствами BIOS со всеми вытекающими ограничениями и неприятностями типа путаницей со способом трансляции адресов блоков и нумерацией дисков.

они только в stage1 должны читаться, ибо ты в 512байт никакой другой, кроме int, программы чтения не засунешь. Потому-то и нужна stage2, дабы обойтись без этих ваших int13, и юзать диск напрямую.

Таким же, как и конфиги — через BIOS. Если же будет модуль для блочного устройства, то — ой: ему, как барону Мюнхаузену, придётся вытягивать себя за косичку из болота.

Таким же, как и конфиги — через BIOS.

это как раз у меня так. Мало того, что через BIOS, дык ещё и фиксированной точки диска. У меня LiLo. А вот граб уже умеет файлы искать, и так далее. Там проще (точнее сложнее), есть stage1, и потом уже идёт stage2, которая фактически — маленькая ОС, даже со своим шеллом, картами, и девочками.

нужна stage2, дабы обойтись без этих ваших int13, и юзать диск напрямую

http://www.bog.pp.ru/work/grub.html

stage1_5 - отдельный модуль для каждого типа файловой системы; ищет и загружает stage2; может находиться в файловой системе или вне её (между MBR и первым разделом или в специально зарезервированном месте FFS или ReiserFS)

stage2 - основной модуль GRUB, обеспечивающий работу с меню и командной строкой

Интересно, зачем в stage2 низкоуровневые драйвера устройств, тогда как работа с файловой системой начинается уже в stage1_5? Не потому ли, что stage2 — более высокий уровень, т.е. меню и командная строка, как видно из цитаты?

Интересно, зачем в stage2 низкоуровневые драйвера устройств

если честно, то я точно не помню. ЕМНИП в stage1_5 только простой драйвер для ФС в /boot/, который только читает, и только эту ФС и как раз через bios. Вот в lilo такого нет, оно прямо так и читает, просто с какого-то сектора. Там ведь не только stage2 надо найти, но и конфиги самого grub'а.

Только шифрование (и то не при всех условиях спасет) ваши данные, от людей которые вытащат хард.
Для остального же достаточно пароля в дисплейном менеджере, для учетки и блокировки экрана.
По сабжу вопроса вот: https://help.ubuntu.com/community/Grub2/Passwords#Protecting_Menuentries

stage1_5 - отдельный модуль для каждого типа файловой системы

Допущение, что в stage2 есть какие-то низкоуровневые дисковые драйвера, приводит к такому усложнению реализации, что в каждом модуле файловой системы нужно как минимум два интерфейса (или многоинтерфейсная прослойка): и для BIOS, и для дискового драйвера stage2. Зачем это надо, если надо всего лишь загрузить kernel и initrd, а обо всём остальном для себя позаботится kernel? Вот еще что наталкивает на мысль:

$ du -sh /boot/grub/ata.mod
8,0K	/boot/grub/ata.mod

$ mcview /boot/grub/ata.mod

Допущение, что в stage2 есть какие-то низкоуровневые дисковые драйвера, приводит к такому усложнению реализации, что в каждом модуле файловой системы нужно как минимум два интерфейса (или многоинтерфейсная прослойка): и для BIOS, и для дискового драйвера stage2

зачем? В stage1_5 есть только модуль для _одной_ ФС, который работает на уровне int13. Этот stage1_5 и загружает stage2, который работает с нужной ФС уже напрямую(многое недоступно через int13, в т.ч. видимо и эти команды для лочки/разлочки HDD).

зачем это надо, если надо всего лишь загрузить kernel и initrd, а обо всём остальном для себя позаботится kernel?

я тоже думаю, что это не нужно, и потому юзаю лило.

В stage1_5 есть только модуль для _одной_ ФС

http://www.bog.pp.ru/work/grub.html

stage1_5 - отдельный модуль для каждого типа файловой системы

Одной != каждой. Не верь глазам своим? :-)

отдельный модуль для каждого типа файловой системы

Одной != каждой.

вопрос понимания. Посмотри хэндбук генты, ЕМНИП, там эта тема подробно раскрыта.

причем тут груб - это через биос