Glenn Washburn <developm...@efficientek.com> writes: > If the configure option --enable-efi-debug is given, then enable the > printing early in EFI startup of the command needed to load symbols for > the GRUB EFI kernel. This is needed because EFI firmware determines where > to load the GRUB EFI at runtime, and so the relevant addresses are not > known ahead of time. This is not printed when secure boot is enabled. > > The command is a custom command defined in the gdb_grub GDB script. So > GDB should be started with the script as an argument to the -x option or > sourced into an active GDB session before running the outputted command. > > Also a command named "gdbinfo" is enabled which allows the user to print > the gdb command string on-demand, which can be valuable as the printing > early in EFI startup is quickly replaced by other text. So if using a > physical screen it may appear too briefly to be registered. > > Co-developed-by: Peter Jones <pjo...@redhat.com> > Signed-off-by: Glenn Washburn <developm...@efficientek.com> > --- > This is patch 9 from the v6 "GDB script fixes and improvements" series, with > one modification. Now the gdbinfo command will print the gdb load command > even when the configure option is not enabled (though still not when lockdown > is enabled). > > Robbie had 2 concerns with the last patch. > > 1. Does this need to be configurable? > * I responded that this was requested by Daniel because of concerns about > it breaking silent boot and it seemed reasonable to me, but that I don't > have a strong opinion. I've left it configurable until Dnaiel weighs in.
Yeah, I think these concerns are valid. The version in the rhboot tree gates printing on an env var. Right now, it seems to me that: - we want it to be default-off because silent boot - we want to have the ability to reenable without rebuilding because secureboot, convenience, etc. > 2. Why should the load command not be printed when secure boot is enabled? > * This was also requested by Daniel, I assume because of infomation leakage > that may be a security concern. I seem to have also missed Daniel's reply about this earlier, which was: >> I think leaking info about the GRUB image addresses on the Secure >> Boot enabled systems is not the best idea. Or do you think having >> this feature enabled by default overweight potential dangers coming >> from its misuse? I don't know how these could help an attacker. They'd need access to console out to retrieve the values, and some way to send input... and that's basically physical presence: at the very least, if they have those, I imagine they'd just edit the menu entries, or drop to the grub shell. Do you see a danger here? Be well, --Robbie
signature.asc
Description: PGP signature
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
