From: Andrew Burgess <aburgess@redhat.com>
To: Christina Schimpe <christina.schimpe@intel.com>,
gdb-patches@sourceware.org
Cc: thiago.bauermann@linaro.org, luis.machado@arm.com
Subject: Re: [PATCH v5 07/12] gdb: amd64 linux coredump support with shadow stack.
Date: Tue, 29 Jul 2025 15:46:42 +0100 [thread overview]
Message-ID: <87o6t3cawd.fsf@redhat.com> (raw)
In-Reply-To: <20250628082810.332526-8-christina.schimpe@intel.com>
Christina Schimpe <christina.schimpe@intel.com> writes:
> Intel's Control-Flow Enforcement Technology (CET) provides the shadow
> stack feature for the x86 architecture.
>
> This commit adds support to write and read the shadow-stack node in
> corefiles. This helps debugging return address violations post-mortem.
> The format is synced with the linux kernel commit "x86: Add PTRACE
> interface for shadow stack". As the linux kernel restricts shadow
> stack support to 64-bit, apply the fix for amd64 only.
>
> Co-Authored-By: Christina Schimpe <christina.schimpe@intel.com>
>
> Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
> ---
> gdb/amd64-linux-tdep.c | 57 ++++++++-
> .../gdb.arch/amd64-shadow-stack-corefile.c | 42 +++++++
> .../gdb.arch/amd64-shadow-stack-corefile.exp | 110 ++++++++++++++++++
> 3 files changed, 205 insertions(+), 4 deletions(-)
> create mode 100644 gdb/testsuite/gdb.arch/amd64-shadow-stack-corefile.c
> create mode 100644 gdb/testsuite/gdb.arch/amd64-shadow-stack-corefile.exp
>
> diff --git a/gdb/amd64-linux-tdep.c b/gdb/amd64-linux-tdep.c
> index edb7d8da6ab..9af7a41ea26 100644
> --- a/gdb/amd64-linux-tdep.c
> +++ b/gdb/amd64-linux-tdep.c
> @@ -47,6 +47,7 @@
> #include "expop.h"
> #include "arch/amd64-linux-tdesc.h"
> #include "inferior.h"
> +#include "x86-tdep.h"
>
> /* The syscall's XML filename for i386. */
> #define XML_SYSCALL_FILENAME_AMD64 "syscalls/amd64-linux.xml"
> @@ -1593,6 +1594,14 @@ amd64_linux_record_signal (struct gdbarch *gdbarch,
> return 0;
> }
>
> +/* Get shadow stack pointer state from core dump. */
> +
> +static bool
> +amd64_linux_core_read_ssp_state_p (bfd *abfd)
> +{
> + return bfd_get_section_by_name (abfd, ".reg-ssp") != nullptr;
I think the comment on this function is not correct. We're not getting
the shadow stack pointer state, we're:
/* Return true if the core file ABFD contains shadow stack pointer
state. Otherwise, return false. */
> +}
> +
> /* Get Linux/x86 target description from core dump. */
>
> static const struct target_desc *
> @@ -1602,11 +1611,14 @@ amd64_linux_core_read_description (struct gdbarch *gdbarch,
> {
> /* Linux/x86-64. */
> x86_xsave_layout layout;
> - uint64_t xcr0 = i386_linux_core_read_xsave_info (abfd, layout);
> - if (xcr0 == 0)
> - xcr0 = X86_XSTATE_SSE_MASK;
> + uint64_t xstate_bv_mask = i386_linux_core_read_xsave_info (abfd, layout);
As with feedback on earlier patches, I don't think the inclusion of
'_mask' is a good one here. I think what you call xstate_bv_mask is an
actual value, not a mask, and should be named 'xstate_bv'
> + if (xstate_bv_mask == 0)
> + xstate_bv_mask = X86_XSTATE_SSE_MASK;
> +
> + if (amd64_linux_core_read_ssp_state_p (abfd))
> + xstate_bv_mask |= X86_XSTATE_CET_U;
>
> - return amd64_linux_read_description (xcr0 & X86_XSTATE_ALL_MASK,
> + return amd64_linux_read_description (xstate_bv_mask & X86_XSTATE_ALL_MASK,
> gdbarch_ptr_bit (gdbarch) == 32);
> }
>
> @@ -1637,6 +1649,35 @@ static const struct regset amd64_linux_xstateregset =
> amd64_linux_collect_xstateregset
> };
>
> +/* Supply shadow stack pointer register from SSP to the register cache
> + REGCACHE. */
> +
> +static void
> +amd64_linux_supply_ssp (const regset *regset,
> + regcache *regcache, int regnum,
> + const void *ssp, size_t len)
> +{
> + x86_supply_ssp (regcache, *static_cast<const uint64_t *> (ssp));
Before this line I'd like to see:
gdb_assert (len == sizeof (uint64_t));
> +}
> +
> +/* Collect the shadow stack pointer register from the register cache
> + REGCACHE and store it in SSP. */
> +
> +static void
> +amd64_linux_collect_ssp (const regset *regset,
> + const regcache *regcache, int regnum,
> + void *ssp, size_t len)
> +{
> + x86_collect_ssp (regcache, *static_cast<uint64_t *> (ssp));
And I think this should get the same 'len == sizeof ...' assert as
above please.
> +}
> +
> +/* Shadow stack pointer register. */
> +
> +static const struct regset amd64_linux_ssp_register
> + {
> + NULL, amd64_linux_supply_ssp, amd64_linux_collect_ssp
> + };
> +
> /* Iterate over core file register note sections. */
>
> static void
> @@ -1653,6 +1694,14 @@ amd64_linux_iterate_over_regset_sections (struct gdbarch *gdbarch,
> cb (".reg-xstate", tdep->xsave_layout.sizeof_xsave,
> tdep->xsave_layout.sizeof_xsave, &amd64_linux_xstateregset,
> "XSAVE extended state", cb_data);
> +
> + /* SSP can be unavailable. Thus, we need to check the register status
> + in case we write a core file (regcache != nullptr). */
> + if (tdep->ssp_regnum > 0
> + && (regcache == nullptr
Have you really seen this function called with 'regcache == nullptr' ?
I'm suspect not as e.g. i386_supply_gregset, which is part of
i386_gregset, makes an unchecked dereference of regcache, so if regcache
was nullptr you'd see UB (crash) before getting to this check.
> + || REG_VALID == regcache->get_register_status (tdep->ssp_regnum)))
> + cb (".reg-ssp", 8, 8, &amd64_linux_ssp_register,
> + "shadow stack pointer", cb_data);
> }
>
> /* The instruction sequences used in x86_64 machines for a
> diff --git a/gdb/testsuite/gdb.arch/amd64-shadow-stack-corefile.c b/gdb/testsuite/gdb.arch/amd64-shadow-stack-corefile.c
> new file mode 100644
> index 00000000000..f078e33810d
> --- /dev/null
> +++ b/gdb/testsuite/gdb.arch/amd64-shadow-stack-corefile.c
> @@ -0,0 +1,42 @@
> +/* This test program is part of GDB, the GNU debugger.
> +
> + Copyright 2025 Free Software Foundation, Inc.
> +
> + This program is free software; you can redistribute it and/or modify
> + it under the terms of the GNU General Public License as published by
> + the Free Software Foundation; either version 3 of the License, or
> + (at your option) any later version.
> +
> + This program is distributed in the hope that it will be useful,
> + but WITHOUT ANY WARRANTY; without even the implied warranty of
> + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + GNU General Public License for more details.
> +
> + You should have received a copy of the GNU General Public License
> + along with this program. If not, see <http://www.gnu.org/licenses/>. */
> +
> +#include <stdio.h>
> +
> +/* Call the return instruction before function epilogue to trigger a
> + control-flow exception. */
> +void
> +function ()
> +{
> + unsigned long ssp;
> + asm volatile("xor %0, %0; rdsspq %0" : "=r" (ssp));
> +
> + /* Print ssp to stdout so that the testcase can capture it. */
> + printf ("%p\n", (void *) ssp);
> + fflush (stdout);
> +
> + /* Manually cause a control-flow exception by executing a return
> + instruction before function epilogue, so the address atop the stack
> + is not the return instruction. */
> + __asm__ volatile ("ret\n");
> +}
> +
> +int
> +main (void)
> +{
> + function (); /* Break here. */
> +}
> diff --git a/gdb/testsuite/gdb.arch/amd64-shadow-stack-corefile.exp b/gdb/testsuite/gdb.arch/amd64-shadow-stack-corefile.exp
> new file mode 100644
> index 00000000000..8784fc3622c
> --- /dev/null
> +++ b/gdb/testsuite/gdb.arch/amd64-shadow-stack-corefile.exp
> @@ -0,0 +1,110 @@
> +# Copyright 2021-2024 Free Software Foundation, Inc.
> +
> +# This program is free software; you can redistribute it and/or modify
> +# it under the terms of the GNU General Public License as published by
> +# the Free Software Foundation; either version 3 of the License, or
> +# (at your option) any later version.
> +#
> +# This program is distributed in the hope that it will be useful,
> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> +# GNU General Public License for more details.
> +#
> +# You should have received a copy of the GNU General Public License
> +# along with this program. If not, see <http://www.gnu.org/licenses/>.
> +
> +# Test the shadow stack pointer note in core dumps.
> +
> +require allow_ssp_tests
> +
> +standard_testfile
> +
> +proc check_core_file {core_filename saved_pl3_ssp} {
> + global decimal
> +
> + # Load the core file.
> + if [gdb_test "core $core_filename" \
> + [multi_line \
> + "Core was generated by .*\\." \
> + "Program terminated with signal SIGSEGV, Segmentation fault.*" \
> + "#0 function \\(\\) at .*amd64-shadow-stack-corefile.c:$decimal" \
> + "$decimal.*__asm__ volatile \\(\"ret\\\\n\"\\);"] \
> + "load core file"] {
> + return
> + }
> +
> + # Check the value of ssp in the core file.
> + gdb_test "print/x \$pl3_ssp" "\\$\[0-9\]+ = $saved_pl3_ssp" \
> + "pl3_ssp contents from core file $saved_pl3_ssp"
> +}
> +
> +save_vars { ::env(GLIBC_TUNABLES) } {
> +
> + append_environment GLIBC_TUNABLES "glibc.cpu.hwcaps" "SHSTK"
> +
> + if { [prepare_for_testing "failed to prepare" $testfile $srcfile \
> + {debug additional_flags="-fcf-protection=return"}] } {
> + return
> + }
> +
> + set linespec ${srcfile}:[gdb_get_line_number "Break here"]
> +
> + if ![runto $linespec] {
> + return
> + }
> +
> + # Continue until a crash. The line with the hex number is optional because
> + # it's printed by the test program, and doesn't appear in the Expect buffer
> + # when testing a remote target.
> + gdb_test "continue" \
> + [multi_line \
> + "Continuing\\." \
> + "($hex\r\n)?" \
> + "Program received signal SIGSEGV, Segmentation fault.*" \
> + "function \\(\\) at .*amd64-shadow-stack-corefile.c:$decimal" \
> + {.*__asm__ volatile \("ret\\n"\);}] \
> + "continue to SIGSEGV"
> +
> + set ssp_in_gcore [get_valueof "/x" "\$pl3_ssp" "*unknown*"]
> +
> + # Generate the gcore core file.
> + set gcore_filename [standard_output_file "${testfile}.gcore"]
> + set gcore_generated [gdb_gcore_cmd "$gcore_filename" "generate gcore file"]
> +
> + # Obtain an OS-generated core file. Save test program output to
> + # ${binfile}.out.
> + set core_filename [core_find $binfile {} {} "${binfile}.out"]
> + set core_generated [expr {$core_filename != ""}]
> + set os_core_name "${binfile}.core"
> + remote_exec build "mv $core_filename $os_core_name"
> + set core_filename $os_core_name
I'm wondering what the point of this core_filename / os_core_name stuff
is? My reading of `core_find` is that the returned core_filename will
be '${binfile}.core', so this whole thing feels redundant, but maybe I'm
missing something here?
> +
> + # At this point we have a couple of core files, the gcore one generated by
> + # GDB and the one generated by the operating system. Make sure GDB can
> + # read both correctly.
> +
> + if {$gcore_generated} {
> + clean_restart $binfile
> +
> + with_test_prefix "gcore corefile" {
> + check_core_file $gcore_filename $ssp_in_gcore
> + }
> + } else {
> + fail "gcore corefile not generated"
It's better, where possible, to avoid having pass/fail results that only
show up down some code paths.
In this case it's easy to avoid having a stray 'fail' by restructuring
the code too:
gdb_assert { $gcore_generated } "gcore corefile created"
if { $gcore_generated } {
... etc ...
}
Now you'll always have either a pass or fail based on the gcore being
generated.
There is also the helper proc `gcore_cmd_available`. I'd guess for any
x86 target that supports SSP, gcore will be available, but in theory you
could consider using this to avoid a fail when gcore is not available
maybe?
> + }
> +
> + if {$core_generated} {
> + clean_restart $binfile
> +
> + with_test_prefix "OS corefile" {
> + # Read ssp value from saved output of the test program.
> + set out_id [open ${binfile}.out "r"]
> + set ssp_in_gcore [gets $out_id]
> +
> + close $out_id
> + check_core_file $core_filename $ssp_in_gcore
I'd move the blank line after the 'close' personally.
Thanks,
Andrew
> + }
> + } else {
> + untested "OS corefile not generated"
> + }
> +}
> --
> 2.43.0
next prev parent reply other threads:[~2025-07-29 14:47 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-28 8:27 [PATCH v5 00/12] Add CET shadow stack support Christina Schimpe
2025-06-28 8:27 ` [PATCH v5 01/12] gdb, testsuite: Extend core_find procedure to save program output Christina Schimpe
2025-07-14 12:21 ` Andrew Burgess
2025-07-17 13:37 ` Schimpe, Christina
2025-06-28 8:28 ` [PATCH v5 02/12] gdbserver: Add optional runtime register set type Christina Schimpe
2025-06-28 8:28 ` [PATCH v5 03/12] gdbserver: Add assert in x86_linux_read_description Christina Schimpe
2025-06-28 8:28 ` [PATCH v5 04/12] gdb: Sync up x86-gcc-cpuid.h with cpuid.h from gcc 14 branch Christina Schimpe
2025-06-28 8:28 ` [PATCH v5 05/12] gdb, gdbserver: Use xstate_bv for target description creation on x86 Christina Schimpe
2025-07-14 13:52 ` Andrew Burgess
2025-07-15 10:28 ` Schimpe, Christina
2025-07-23 12:47 ` Schimpe, Christina
2025-08-05 13:47 ` Andrew Burgess
2025-06-28 8:28 ` [PATCH v5 06/12] gdb, gdbserver: Add support of Intel shadow stack pointer register Christina Schimpe
2025-07-25 12:49 ` Andrew Burgess
2025-07-25 15:03 ` Schimpe, Christina
2025-08-01 12:54 ` Schimpe, Christina
2025-08-05 13:57 ` Andrew Burgess
2025-08-06 19:53 ` Schimpe, Christina
2025-08-06 19:54 ` Schimpe, Christina
2025-08-07 3:17 ` Thiago Jung Bauermann
2025-08-14 11:39 ` Andrew Burgess
2025-07-29 13:51 ` Andrew Burgess
2025-08-01 12:40 ` Schimpe, Christina
2025-08-10 19:01 ` H.J. Lu
2025-08-10 20:07 ` Schimpe, Christina
2025-06-28 8:28 ` [PATCH v5 07/12] gdb: amd64 linux coredump support with shadow stack Christina Schimpe
2025-07-29 14:46 ` Andrew Burgess [this message]
2025-07-30 1:55 ` Thiago Jung Bauermann
2025-07-30 11:42 ` Schimpe, Christina
2025-08-04 15:28 ` Schimpe, Christina
2025-08-05 4:29 ` Thiago Jung Bauermann
2025-08-05 15:29 ` Schimpe, Christina
2025-08-06 20:52 ` Luis
2025-08-11 11:52 ` Schimpe, Christina
2025-08-04 12:45 ` Schimpe, Christina
2025-06-28 8:28 ` [PATCH v5 08/12] gdb: Handle shadow stack pointer register unwinding for amd64 linux Christina Schimpe
2025-07-30 9:58 ` Andrew Burgess
2025-07-30 12:06 ` Schimpe, Christina
2025-06-28 8:28 ` [PATCH v5 09/12] gdb, gdbarch: Enable inferior calls for shadow stack support Christina Schimpe
2025-07-30 10:42 ` Andrew Burgess
2025-06-28 8:28 ` [PATCH v5 10/12] gdb: Implement amd64 linux shadow stack support for inferior calls Christina Schimpe
2025-07-30 11:58 ` Andrew Burgess
2025-07-31 12:32 ` Schimpe, Christina
2025-06-28 8:28 ` [PATCH v5 11/12] gdb, gdbarch: Introduce gdbarch method to get the shadow stack pointer Christina Schimpe
2025-07-30 12:22 ` Andrew Burgess
2025-08-04 13:01 ` Schimpe, Christina
2025-08-14 15:50 ` Andrew Burgess
2025-08-19 15:37 ` Schimpe, Christina
2025-06-28 8:28 ` [PATCH v5 12/12] gdb: Enable displaced stepping with shadow stack on amd64 linux Christina Schimpe
2025-07-30 13:59 ` Andrew Burgess
2025-07-31 17:29 ` Schimpe, Christina
2025-07-08 15:18 ` [PATCH v5 00/12] Add CET shadow stack support Schimpe, Christina
2025-08-14 7:52 ` Schimpe, Christina
2025-07-11 10:36 ` Luis Machado
2025-07-11 13:54 ` Schimpe, Christina
2025-07-11 15:54 ` Luis Machado
2025-07-13 14:01 ` Schimpe, Christina
2025-07-13 19:05 ` Luis Machado
2025-07-13 19:57 ` Schimpe, Christina
2025-07-14 7:13 ` Luis Machado
2025-07-17 12:01 ` Schimpe, Christina
2025-07-17 14:59 ` Luis Machado
2025-07-23 12:45 ` Schimpe, Christina
2025-07-28 17:05 ` Luis Machado
2025-07-28 17:20 ` Schimpe, Christina
2025-08-20 9:16 ` Schimpe, Christina
2025-08-20 15: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=87o6t3cawd.fsf@redhat.com \
--to=aburgess@redhat.com \
--cc=christina.schimpe@intel.com \
--cc=gdb-patches@sourceware.org \
--cc=luis.machado@arm.com \
--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