Re: grubenv on md, Btrfs, LUKS, etc

[Chris Murphy]

On Fri, Sep 21, 2018 at 12:35 PM, Daniel Kiper <address@hidden> wrote:
> On Tue, Sep 18, 2018 at 01:40:06PM -0600, Chris Murphy wrote:
>> On Mon, Sep 17, 2018 at 10:59 PM, Chris Murphy <address@hidden> wrote:
>> > Hi,
>> >
>> > GRUB code can certainly read files that are on Btrfs, md devices,
>> > LUKS, LVM, and so on. But GRUB code can also write to the physical
>> > block for grubenv - but are there safe guards that prevent it from
>> > doing so if grubenv is on something like Btrfs, mdadm raid5, LUKS?
>> >
>> > And also what about XFS? This used to be safe, but now with reflink
>> > support, grubenv could be reflink copied, meaning any overwrite is
>> > disallowed and must be COW'd. How is that handled?
>> >
>> > I'm pretty sure on Btrfs GRUB knows is can't write to grubenv, I'm
>> > just curious about the other cases.
>>
>> OK so it allows me to create a grubenv on Btrfs without any complaint.
>> Will the bootloader actually try to write to this if grub.cfg contains
>> save_env?
>>
>> $ sudo grub2-editenv --verbose grubenv create
>> [sudo] password for chris:
>> address@hidden ~]$ ll
>> -rw-r--r--. 1 root  root     1024 Sep 18 13:37 grubenv
>> address@hidden ~]$ stat -f grubenv
>>   File: "grubenv"
>>     ID: ac9ba8ecdce5b017 Namelen: 255     Type: btrfs
>> Block size: 4096       Fundamental block size: 4096
>> Blocks: Total: 46661632   Free: 37479747   Available: 37422535
>> Inodes: Total: 0          Free: 0
>> address@hidden ~]$
>
> There two things here. grub2-editenv should create grubenv properly
> and double check that space on disk is reserved. If it is not then
> it should complain. GRUB2 during boot should check was grubenv file
> properly created. If it was not it should not update grubenv and
> complain.
>
> I am not sure is anything like that implemented in GRUB2. If does
> not I am happy to see and review the patches.

When I create a grubenv on Btrfs is does succeed and it's an inline
extent, so no mattter what it's checksummed. There is a message on the
next boot:

error: ../../grub-core/commands/loadenv.c:215:sparse file not allowed.

And the grubenv is not overwritten even though the grub.cfg is using
save_env and when this same grub.cfg is used on ext4 it does overwrite
grubenv. So... It appears loadenv.c must have some inhibitor for
writing to Btrfs, which is a good thing.

I'm uncertain whether GRUB avoids writing to any other case (LUKS, md
RAID, LVM). In particular, XFS, because XFS now supports reflinks, so
strictly speaking even if overwriting 2 sectors does not cause
corruption today (no inline extent support yet), it probably should
refuse to write to XFS as well.

Anyway, I've got a couple of different opinions from XFS devel@ and
ext4 devel@ about this. My understanding is each file system (ext4,
XFS, Btrfs at least) have reserve areas that can reliably be written
to by the bootloader (pre-boot), and it seems like those need to be
used instead of depending on grubenv.

https://www.spinics.net/lists/linux-ext4/msg62364.html

https://www.spinics.net/lists/linux-xfs/msg21902.html


Thanks,

-- 
Chris Murphy