Re: Behaviour if GRUB_ENABLE_CRYPTODISK is unset?

["Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2353 bytes --]

On 08.12.2013 00:42, Chris Murphy wrote:
> 
> On Dec 7, 2013, at 7:00 AM, Colin Watson <cjwatson@ubuntu.com> 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
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]