Re: Behaviour if GRUB_ENABLE_CRYPTODISK is unset?

[Chris Murphy]

On Dec 7, 2013, at 7:00 AM, Colin Watson <address@hidden> wrote:

> On Sat, Dec 07, 2013 at 02:49:45PM +0100, Vladimir 'φ-coder/phcoder' 
> Serbinenko wrote:
>> On 07.12.2013 14:27, Colin Watson wrote:
>>> I've never totally understood why GRUB_ENABLE_CRYPTODISK is optional to
>>> begin with; it seems like a bit of a "do you want things to work? [y/N]"
>>> option to me.  My preferred approach would be to delete the option. 
>> 
>> Cryptodisk support is allowed to ask user for password which is not
>> possible for unattended systems.
>> E.g. in old config GRUB was looking for unifont under /usr/share. If you
>> make cryptodisk default a server doing this would stop in password
>> prompt rather than skipping unifont and going to text mode and
>> continuing booting.
> 
> OK.  I get that we don't necessarily want to be noisy if it's just for
> something optional.  But if somebody's /boot is on LUKS, it would be
> nice to tell them how to enable support for that rather than just having
> grub-mkconfig fail, right?  I think grub-install already gives specific
> instructions, so we could do that in grub-mkconfig too.

Encrypted /boot seems to be an edge case, at least for x86 UEFI, on which 
increasingly systems are shipping with a firmware that doesn't initialize USB 
at all in order shave off boot time. For these systems, as far as I know, GRUB, 
or any boot manager, can't initialize USB while boot services is still active. 
So we're looking at systems with no interactive means to manipulate a boot menu 
at boot time, or type in passwords. Instead it seems we need an application 
that modifies e.g. grubenv so the grub.cfg knows what to boot. 

Anyway, I'm uncertain about the benefit of encrypted /boot. If boot files are 
supposed to be protected from modification then that's what secure boot is for.


Chris Murphy