Re: [PATCH 0/4] EFI envblk

[Glenn Washburn]

On Thu, 27 Jul 2023 00:49:06 +0300
"Vladimir 'phcoder' Serbinenko" <phcoder@gmail.com> wrote:

> Have you considered that some firmwares brick if EFI storage is over 50%
> full? Why not having a file on ESP instead?

What if the ESP is readonly? What if there is no ESP? I take your point
about crappy firmwares. As mentioned these patches come from RedHat's
downstream GRUB and I believe they are using them in production. So
apparently this hasn't been an issue for their users. Now I suspect
its probably almost never getting used, so perhaps its a low
probability that the issue you mention is seen.

Should there be giant warnings in the usage, documentation, or command
execution (with confirmation)? How big of a problem is it really
(considering the likelihood that this might be used on one of those
machines)?

Glenn

> 
> Le jeu. 27 juil. 2023, 00:09, Glenn Washburn <development@efficientek.com>
> a écrit :
> 
> > This patch series (for me) was motivated by the "gdb: Add more support for
> > debugging on EFI platforms" patch series, which allowed printing in early
> > EFI init of the GDB command for properly loading symbols. That approach of
> > having the functionality be included at compile time was ultimately
> > rejected. During the discussion of that series, Robbie suggested[1] using
> > patches by Peter and in the Redhat downstream repo which uses an EFI
> > variable to store a GRUB env block. Using this, a user could store a
> > variable in the env block stored in the EFI variable and then have GRUB
> > load that env block in early init as a way to enable the printing of the
> > GDB command.
> >
> > I've taken the original patches by Peter, made more suitable for including
> > in GRUB, fixed some bugs, and added a minor feature. The first patch, adds
> > env block loading in early EFI init from the GRUB_ENV EFI variable. The
> > second patch is included to provide tools for GRUB to set this EFI env
> > block itself, as opposed to needing to use the method suggested by
> > Robbie[1], which requires GNU/Linux and the user-space grub2-editenv
> > utility. Of course, if GRUB is crashing before one can run the
> > efi-export-env command, then other ways of creating and setting the EFI
> > envblk variable are necessary. The third patch adds a test which checks the
> > usability of the commands and the early init loading. And the last patch,
> > whichvmotivated this series, prints the GDB command string if the GRUB
> > variable named "enable_earlyinit_gdbinfo" is present and is set to "1",
> > after
> > the env block is loaded from the GRUB_ENV EFI variable. We might want a
> > different name for the GRUB variable, I don't really have a preference.
> >
> > Glenn
> >
> > [1] https://mail.gnu.org/archive/html/grub-devel/2023-03/msg00072.html
> >
> > Glenn Washburn (2):
> >   tests: Add efienv_test for testing efi-export-env and efi-load-env
> >   efi: Print GDB command for loading symbols if variable exists
> >
> > Peter Jones (2):
> >   efi: Load env block from GRUB_ENV EFI variable in early init
> >   efi: Add efi-export-env and efi-load-env commands
> >
> >  Makefile.util.def            |   6 ++
> >  docs/grub.texi               |  24 +++++
> >  grub-core/Makefile.core.def  |   7 ++
> >  grub-core/commands/efi/env.c | 182 +++++++++++++++++++++++++++++++++++
> >  grub-core/kern/efi/efi.c     |   3 +
> >  grub-core/kern/efi/init.c    |  37 +++++++
> >  grub-core/lib/envblk.c       |  43 +++++++++
> >  include/grub/efi/efi.h       |   5 +
> >  include/grub/lib/envblk.h    |   3 +
> >  tests/efienv_test.in         |  57 +++++++++++
> >  10 files changed, 367 insertions(+)
> >  create mode 100644 grub-core/commands/efi/env.c
> >  create mode 100644 tests/efienv_test.in
> >
> > --
> > 2.34.1
> >
> >
> > _______________________________________________
> > Grub-devel mailing list
> > Grub-devel@gnu.org
> > https://lists.gnu.org/mailman/listinfo/grub-devel
> >