Also we need to add safeguards to never fill more than half of variable storage, same as Linux. Just to avoid bricking bad firmwares
On Mon, 30 Sep 2019, 13:16 Daniel Kiper, <dki...@net-space.pl> wrote: > On Sun, Sep 15, 2019 at 05:14:02PM +0200, Sam van Kampen via Grub-devel > wrote: > > Hey all, > > > > To solve a problem I faced on my own system I've been working on a > > patch that adds support for viewing and editing EFI Boot* variables > > (BootOrder, BootNext, BootXXXX) from GRUB, and was wondering if there > > was any interest in including the functionality upstream. > > > > In its current form, the patch adds a new module (efibootvars.mod), > > which adds the commands `bootnext`, `bootentries` and `bootorder`. > > > > My plan is to send the patch for review once I've finished view and > > edit functionality for `bootnext` and `bootorder`. `bootentries` can > > currently only show BootXXXX variables - I might add support for > > editing them in a subsequent patch, but they are a significantly more > > complex data structure (EFI_LOAD_OPTION), hence editing is not > > currently included. > > > > Please let me know what you think, > > Makes sense for me. So, please post it. Though I would consider > disabling that functionality if UEFI secure boot is enabled. Please > take a look at grub-core/commands/efi/shim_lock.c for more details. > > Daniel > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel >
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
