From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1g5ZJ7-0003r3-CQ for mharc-grub-devel@gnu.org; Thu, 27 Sep 2018 12:38:29 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59841) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g5ZJ5-0003qx-Ba for grub-devel@gnu.org; Thu, 27 Sep 2018 12:38:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g5ZJ2-0006U8-In for grub-devel@gnu.org; Thu, 27 Sep 2018 12:38:27 -0400 Received: from dibed.net-space.pl ([84.10.22.86]:56638) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_3DES_EDE_CBC_SHA1:24) (Exim 4.71) (envelope-from ) id 1g5ZJ2-0006TL-4u for grub-devel@gnu.org; Thu, 27 Sep 2018 12:38:24 -0400 Received: (from localhost user: 'dkiper' uid#4000 fake: STDIN (dkiper@dibed.net-space.pl)) by router-fw-old.i.net-space.pl id S1871608AbeI0QiV (ORCPT ); Thu, 27 Sep 2018 18:38:21 +0200 Date: Thu, 27 Sep 2018 18:38:21 +0200 From: Daniel Kiper To: Chris Murphy Cc: Daniel Kiper , The development of GNU GRUB Subject: Re: grubenv on md, Btrfs, LUKS, etc Message-ID: <20180927163821.GF22053@router-fw-old.i.net-space.pl> References: <20180921183503.GE29978@router-fw-old.i.net-space.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 84.10.22.86 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2018 16:38:28 -0000 On Wed, Sep 26, 2018 at 04:45:51PM -0600, Chris Murphy wrote: > On Fri, Sep 21, 2018 at 12:35 PM, Daniel Kiper 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 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: > >> [chris@f29h ~]$ ll > >> -rw-r--r--. 1 root root 1024 Sep 18 13:37 grubenv > >> [chris@f29h ~]$ 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 > >> [chris@f29h ~]$ > > > > 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. Great! That is in line with what I said earlier. > 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. Yep! > 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 If something like that exits I am happy to use it. However, I would not change user interface in any way. Everything should happen auto-magically from user POV. Daniel