grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Behaviour if GRUB_ENABLE_CRYPTODISK is unset?


From: Vladimir 'φ-coder/phcoder' Serbinenko
Subject: Re: Behaviour if GRUB_ENABLE_CRYPTODISK is unset?
Date: Sun, 08 Dec 2013 00:54:32 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10

On 08.12.2013 00:42, Chris Murphy wrote:
> 
> 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.
> 
> 
That's all beside the original topic of this thread. This is unfortunate
that this becomes a tendency on this list to usurp threads for unrelated
comments.
And note that encrypted /boot as part of encrypted / is easier to manage
in some cases
> Chris Murphy
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/grub-devel
> 


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]