On Thu, 22 Dec 2022 19:17:31 +0100 Daniel Kiper <dki...@net-space.pl> wrote:
> On Wed, Dec 21, 2022 at 11:57:33AM -0600, Glenn Washburn wrote: > > On Wed, 21 Dec 2022 16:20:17 +0100 > > Daniel Kiper <dki...@net-space.pl> wrote: > > > > > Adding Robbie... > > > > > > Please CC him next time when you post these patches. I would want > > > to hear his opinion too. Or at least he is aware what is happening > > > here... > > > > Sure, I CC'd him and Peter on the first couple of ones. But there > > was > > Thank you! > > > never had a response in the 4 months since then, so I figured they > > didn't care. > > Until somebody ask you to not include themselves in the thread please > CC them. AFAICT many people read emails often, like me, but jump into > discussion when something really important for them is happening. > > > > On Thu, Dec 15, 2022 at 11:29:31PM -0600, Glenn Washburn wrote: > > > > If the macro PRINT_GDB_SYM_LOAD_CMD is non-zero, compile code > > > > which > > Why is this not a flag, like e.g. --enable-mm-debug, for the > configure? I had thought about it, and honestly, I was hoping someone would have a better idea on the user interface. It feels clunky to me, so I wasn't really wanting to advertise it. I think I'll add it in the next version. > > > > > will print 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. > > > > > > > > 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. > > > > > > I think this functionality should be disabled when lockdown is > > > enforced, e.g. on UEFI platforms with Secure Boot enabled. > > > > Since this is off by default and must be enabled at build time, > > then if the builder enabled it, they really did want it, regardless > > of lockdown. What you're worried about seems highly improbable to > > me (but then I don't know the inner workings of the distros). The > > concern as I understand it, is that someone doing an official > > release of a distro which will be secure boot ready will > > accidentally have this build time macro enabled. That's almost > > inconceivable to me, but I'm curious what the others have to say > > (especially since Robbie posted a similar patch that always printed > > this info as a debug message[1]). Or is it more about a regular > > user signing with their own keys accidentally shooting themselves > > in the foot by forgetting to disable this (after having already > > enabled it) and then some physical attacker getting extra info to > > do an evil maid attack? > > I can imagine that a distro builds and signs GRUB with debug embedded > and then somebody in the wild wants to enable this feature to debug a > problem. Of course them cannot rebuild the GRUB image because it is > signed. However, them can disable UEFI Secure Boot and enable > debugging. Of course this probably will not work in all cases but > should help solve most problems. As I understand it then, the main downside is that debugging in lockdown mode doesn't get any easier to debug. I guess I don't see that affecting me terribly, so I'm not opposed to it. Thinking about this more, I think I should add a command called "gdbinfo" which also prints out this info on-demand by the user. I'll have it disabled in lockdown mode too. I think this will make it nicer for someone debugging issues with GRUB on real hardware and where the issue is not in early boot. As it is now, I think the output would too quickly disappear from the physical screen for it to be useful. Glenn _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
