[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC PATCH] gdb: Add more support for debugging on EFI platforms

From: Glenn Washburn
Subject: Re: [RFC PATCH] gdb: Add more support for debugging on EFI platforms
Date: Wed, 15 Mar 2023 03:07:34 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0

On 3/9/23 23:00, Robbie Harwood wrote:
Glenn Washburn <> 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 <>
Signed-off-by: Glenn Washburn <>
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

I understand you to be talking about a default-off at runtime, not built time. Right now there is a configure option which defaults to off, is this acceptable?

- we want to have the ability to reenable without rebuilding because
   secureboot, convenience, etc.

This would be great, but how do you propose that this would work? This patch will print very early in EFI init. We can't use GRUB variables. We probably could use EFI variables, but this needs to be well defined (and not by me, since I don't have this requirement). I'm not sure if the GRUB env block is available at this point, but that might be an option.

Can you point me to RH's patch you've referred to? Does it meet this requirement, and if so how?


  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

Do you see a danger here?

Be well,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]