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

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 <[email protected]>
> Sent: Thursday, December 21, 2023 11:27 PM
> To: Schimpe, Christina <[email protected]>
> Cc: [email protected]
> 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" <[email protected]> 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