[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
>
signature.asc
Description: OpenPGP digital signature
Re: Behaviour if GRUB_ENABLE_CRYPTODISK is unset?, Andrey Borzenkov, 2013/12/07