All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robbie Harwood <rharwood@redhat.com>
To: Glenn Washburn <development@efficientek.com>,
	grub-devel@gnu.org, Daniel Kiper <dkiper@net-space.pl>
Cc: Glenn Washburn <development@efficientek.com>,
	Peter Jones <pjones@redhat.com>
Subject: Re: [RFC PATCH] gdb: Add more support for debugging on EFI platforms
Date: Thu, 09 Mar 2023 18:00:04 -0500	[thread overview]
Message-ID: <jlgzg8lpm2z.fsf@redhat.com> (raw)
In-Reply-To: <20230227213526.2379718-1-development@efficientek.com>

[-- Attachment #1: Type: text/plain, Size: 2756 bytes --]

Glenn Washburn <development@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 <pjones@redhat.com>
> Signed-off-by: Glenn Washburn <development@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

  reply	other threads:[~2023-03-09 23:00 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-27 21:35 [RFC PATCH] gdb: Add more support for debugging on EFI platforms Glenn Washburn
2023-03-09 23:00 ` Robbie Harwood [this message]
2023-03-10 20:27   ` Peter Jones
2023-03-13 12:27     ` Daniel Kiper
2023-03-15  3:11       ` Glenn Washburn
2023-03-16 14:55         ` Daniel Kiper
2023-03-15  3:07   ` Glenn Washburn
2023-03-16 21:05     ` Robbie Harwood
2023-03-21 17:02       ` Glenn Washburn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jlgzg8lpm2z.fsf@redhat.com \
    --to=rharwood@redhat.com \
    --cc=development@efficientek.com \
    --cc=dkiper@net-space.pl \
    --cc=grub-devel@gnu.org \
    --cc=pjones@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.