From: "Schimpe, Christina" <christina.schimpe@intel.com>
To: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Cc: "gdb@sourceware.org" <gdb@sourceware.org>
Subject: RE: Shadow stack command to host related subcommands (was Re: Shadow stack backtrace command name)
Date: Tue, 9 Jan 2024 08:34:17 +0000 [thread overview]
Message-ID: <SN7PR11MB76389F312230D16B77FF5041F96A2@SN7PR11MB7638.namprd11.prod.outlook.com> (raw)
In-Reply-To: <87h6kbfazh.fsf@linaro.org>
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
next prev parent reply other threads:[~2024-01-09 8:34 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-20 9:42 Shadow stack backtrace command name Schimpe, Christina
2023-12-20 10:59 ` Guinevere Larsen
2023-12-20 15:11 ` Schimpe, Christina
2023-12-20 11:38 ` Luis Machado
2023-12-20 15:35 ` Schimpe, Christina
2023-12-20 15:57 ` Luis Machado
2023-12-21 4:35 ` Thiago Jung Bauermann
2023-12-21 22:26 ` Shadow stack command to host related subcommands (was Re: Shadow stack backtrace command name) Thiago Jung Bauermann
2024-01-09 8:34 ` Schimpe, Christina [this message]
2023-12-23 18:22 ` Shadow stack backtrace command name Tom Tromey
2023-12-28 22:34 ` Thiago Jung Bauermann
2024-01-09 10:21 ` Schimpe, Christina
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=SN7PR11MB76389F312230D16B77FF5041F96A2@SN7PR11MB7638.namprd11.prod.outlook.com \
--to=christina.schimpe@intel.com \
--cc=gdb@sourceware.org \
--cc=thiago.bauermann@linaro.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).