Re: [PATCH v4 08/15] gdb: If enabled, print line used to load EFI kernel symbols when using gdb_grub script

[Glenn Washburn]

On Thu, 22 Dec 2022 19:17:31 +0100
Daniel Kiper <dkiper@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 <dkiper@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