RE: Shadow stack command to host related subcommands (was Re: Shadow stack backtrace command name)

Schimpe, Christina via Gdb
2024-01-09T08:35:40Z

Hi Thiago,

For "info shadow-stack enabled":
We will expose the shadow stack pointer as register, so the user can
check if it is available.
It is only available in case shadow stack is enabled for a program.
Based on that, I don't see the need to have an extra command
for shadow stack enablement state, I think.

In case the user runs "bt -shadow" and shadow-stack is not enabled,
we could also provide a useful command output.

For "info shadow-stack locked":
We don't have a separate note for such a feature a but similar information
would be available using "/proc/$PID/status", which the user could check
himself:
https://github.com/torvalds/linux/commit/0ee44885fe9cf19eb3870947c8f3c275017e48a7

So I am not sure if the two commands would make much sense for our case.

Does that sound reasonable to you?

Christina

> -----Original Message-----
> From: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
> Sent: Thursday, December 21, 2023 11:27 PM
> To: Schimpe, Christina <christina.schimpe@intel.com>
> Cc: gdb@sourceware.org
> Subject: Shadow stack command to host related subcommands (was Re:
> Shadow stack backtrace command name)
>
>
> Hello again,
>
> This isn't about backtrace, but still related to your proposal I think.
>
> "Schimpe, Christina via Gdb" <gdb@sourceware.org> writes:
>
> > It is configurable using "print symbol-filename" and COUNT.
> > The command can be called by the following names:
> > - "info shadow-stack bt", "info shadow-stack backtrace"
> >
> > From my perspective, the command name has the following pros and cons:
> > (+) Easy to understand by just looking at the command name.
> > (-) Rather long syntax
>
> As I mentioned yesterday, I like the "bt -shadow" proposal but I'd also like to
> have an "info shadow-stack" command (or just "shadow-stack" as suggested by
> Guinevere) to hang a couple of GCS subcommands onto, e.g.:
>
> info shadow-stack enabled
> info shadow-stack locked
>
> which would get/set the GCS features that are enabled or locked. These
> correspond to a couple of entries in the structure returned by ptrace's
> NT_ARM_GCS regset in Linux:
>
> struct user_gcs
> {
> uint64_t features_enabled;
> uint64_t features_locked;
> uint64_t gcspr_el0;
> };
>
> Initially I thought of exposing them as pseudo-registers, but this way seems more
> straightforward.
>
> What do you think? Would this be useful for Intel CET as well?
>
> --
> Thiago
Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928