From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id Ew/rNQgppGf80iUAWB0awg (envelope-from ) for ; Wed, 05 Feb 2025 22:14:16 -0500 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=linaro.org header.i=@linaro.org header.a=rsa-sha256 header.s=google header.b=u3tF8yYU; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id CE0AB1E105; Wed, 5 Feb 2025 22:14:16 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.0 Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id A90DD1E05C for ; Wed, 5 Feb 2025 22:14:15 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 53EF43858C51 for ; Thu, 6 Feb 2025 03:14:15 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 53EF43858C51 Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=linaro.org header.i=@linaro.org header.a=rsa-sha256 header.s=google header.b=u3tF8yYU Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) by sourceware.org (Postfix) with ESMTPS id CEBC53858408 for ; Thu, 6 Feb 2025 03:13:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CEBC53858408 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org CEBC53858408 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::634 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1738811623; cv=none; b=wiYQinOignBOUZ0eD+4PYeI/2wgm/YSaEszVQWVVSaAuwfSF2MoLu5993CdYEf7Oh1fO7llPIt/j7fMMm/f6NyIRJGbg5NBQjWOyKt2imI5x9rHRd/uNpxtPH5XvEEqDyiTqSBINoIZyAIfU3VHFJXy68RrM7kaFXl2adeP2ZyQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1738811623; c=relaxed/simple; bh=VkYaweU15qS6Emp87yvsnZHBQmoQ8o+LXflbGR0obH0=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=HOREt3+2tRej12cPXxxVpoW9t8RxHCug8Mf+M/OXzww5dmjrS+McCmGfSj/WnMgfS+qMIXEmIgJM9rtpRvbD7qC/AyvJP7hu/imdV/oSxhpZdzIr+l4T1BaQk7Qwgy/uaTIBZekeKrM8j2p1e2+tp25yq9fs80kJxVKfy2j6zEo= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CEBC53858408 Received: by mail-pl1-x634.google.com with SMTP id d9443c01a7336-21f2339dcfdso6248085ad.1 for ; Wed, 05 Feb 2025 19:13:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1738811622; x=1739416422; darn=sourceware.org; h=mime-version:message-id:date:user-agent:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=fafLlZEe5Fot6a6R4zKpaECGs12plaNxOFMKGRvUc7w=; b=u3tF8yYUxrqQZnbZg9d81bLP+gzxjeCHbTCrzrpCQWjD71mrMxo7eir+3ScTV/sZFR nPGszPVHJoDnUz8OSq4X5gOBR3NHjUks2+1wbC6Cr2mJR9vzsOym9eDXQBhq5UEqt/pd 7JxKnPFJIz52ERWaEwMPN2f+VgglaL7hrec4sICmMrSGdze+ES2S0XhdZnlLHRUiAsSU mYZZG+AgA+kj4xgY1m3CW3kk0A4vwdA3IHXooi2WEC8cScdq4B7C9BDn9NRcH3lo+tuN LK9kFnn70mqqhPWOcfrLsmplT0RXeOjrD4vi3HqjxuLNYdV9oZ4krgGuYerCV8T+AA0H C41A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738811622; x=1739416422; h=mime-version:message-id:date:user-agent:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=fafLlZEe5Fot6a6R4zKpaECGs12plaNxOFMKGRvUc7w=; b=ViezC54E5LOHW+IxGtqLB+NSbj/GazbADwST8Qs8DJFLOqpviqtnSJOrzEtbzVCQ2m XurujRdVxAryGv+n6jTofVRBAcO793RGk25mhneQwomcdtCLLwCelk4Lh1cYbCNkSAy6 JB81j+r7Fg7YI3+99Ar9UMaVZDIvK8oH4Eu/PVhZZUj7VrfioOTExgi7SqPVV/8MCNuK KbFSkjW7GZy921arS+pBE7BAtSmBFJspa43OgmPRIbXoLozkCV0eNcmpxOEcdO4f+JXt jHl/Oy8SkYWzj1oQFgLm8cMqkXqcDhcf9JbpCgAJePt60BK2IFieNOV7btP81vpoeMqk UuWg== X-Gm-Message-State: AOJu0YzJyTk56qYq1pO+T4VUxOG7s84tL37rVQwPz2WwWnyIrUa2FRUp TXmb0FnFQp9PiT2cj5jY3LHEAUfO4fW5c8A04mBtiBQDdS9gcv+9rPNjTr4UpK20uRMcswK1Qb8 v X-Gm-Gg: ASbGncswHsSo3SZS8wegOrragkdyratoqmnk8aLE9AdK5zwhUaN6RwI9WsqlnuYPk1d OdiQYJ0yAfkYLyJCx9YCshr9uJLG0hyV5eGJ0nUbV4jaURZwK9wTDeyS/gIhDBz0PhIRkY/jpvr 0cynrN3Ea7u95fjrTlcayvTR72VCyT5Ox2tJPVXwYqL+ZtJIR4qhntqrQ9ffA13e3oB6y8TGzPx PddcNWa3ymu0YyD6Y022Mqy9A4vjjjdbXdfQIrKHppe1JgvkajYsqyV0SJKXYsDIfVy31fmdxSi WhDA5muBjVSdignCQOAkuK4= X-Google-Smtp-Source: AGHT+IEfVyKGCZj/MFRLI6zuh8fFcy/Qe/q1/KIshCKmS/Y6LWffIlkuXhtGSh727+6/CcXC+W94oQ== X-Received: by 2002:a17:902:e84f:b0:216:4fad:35d0 with SMTP id d9443c01a7336-21f2f1698eemr28359185ad.9.1738811621598; Wed, 05 Feb 2025 19:13:41 -0800 (PST) Received: from localhost ([2804:14d:7e39:8470:7e5:16be:a0c6:ff7]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-21f3683d8ffsm1443555ad.150.2025.02.05.19.13.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Feb 2025 19:13:41 -0800 (PST) From: Thiago Jung Bauermann To: "Schimpe, Christina" Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 06/12] gdb, gdbserver: Add support of Intel shadow stack pointer register. In-Reply-To: <20241220200501.324191-7-christina.schimpe@intel.com> (Christina Schimpe's message of "Fri, 20 Dec 2024 20:04:55 +0000") References: <20241220200501.324191-1-christina.schimpe@intel.com> <20241220200501.324191-7-christina.schimpe@intel.com> User-Agent: mu4e 1.12.8; emacs 29.4 Date: Thu, 06 Feb 2025 00:13:38 -0300 Message-ID: <877c63ix3x.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org "Schimpe, Christina" writes: > This patch adds the user mode register PL3_SSP which is part of the > Intel(R) Control-Flow Enforcement Technology (CET) feature for support > of shadow stack. > For now, only native and remote debugging support for shadow stack > userspace on amd64 linux are covered by this patch including 64 bit and > x32 support. 32 bit support is not covered due to missing linux kernel Nit: Linux (uppercase l) > support. > diff --git a/gdb/arch/i386.c b/gdb/arch/i386.c > index 4a39028a472..59daaa4c583 100644 > --- a/gdb/arch/i386.c > +++ b/gdb/arch/i386.c > @@ -28,6 +28,7 @@ > #include "../features/i386/32bit-avx512.c" > #include "../features/i386/32bit-segments.c" > #include "../features/i386/pkeys.c" > +#include "../features/i386/32bit-ssp.c" > > /* See i386.h. */ > > @@ -66,5 +67,8 @@ i386_create_target_description (uint64_t xstate_bv_mask, bool is_linux, > if (xstate_bv_mask & X86_XSTATE_PKRU) > regnum = create_feature_i386_pkeys (tdesc.get (), regnum); > > + if (xstate_bv_mask & X86_XSTATE_CET_U) > + regnum = create_feature_i386_32bit_ssp (tdesc.get (), regnum); > + > return tdesc.release (); > } The patch description mentions that "32 bit support is not covered due to missing linux kernel support". Is this change useful, or is it unreachable code? > diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp > index a86f534528c..fc35456f1d3 100644 > --- a/gdb/testsuite/lib/gdb.exp > +++ b/gdb/testsuite/lib/gdb.exp > @@ -4225,6 +4225,75 @@ gdb_caching_proc allow_tsx_tests {} { > return $allow_tsx_tests > } > > +# Run a test on the target to check if it supports x86 shadow stack. Return 1 > +# if shadow stack is enabled, 0 otherwise. > + > +gdb_caching_proc allow_ssp_tests {} { > + global srcdir subdir gdb_prompt hex > + > + set me "allow_ssp_tests" > + > + if { ![istarget i?86-*-*] && ![istarget x86_64-*-* ] } { > + verbose "$me: target known to not support shadow stack." > + return 0 > + } > + > + # There is no need to check the actual HW in addition to ptrace support. > + # We need both checks and ptrace will tell us about the HW state. > + set compile_flags "{additional_flags=-fcf-protection=return}" > + set src { int main() { return 0; } } > + if {![gdb_simple_compile $me $src executable $compile_flags]} { > + return 0 > + } > + > + save_vars { ::env(GLIBC_TUNABLES) } { > + > + append_environment GLIBC_TUNABLES "glibc.cpu.hwcaps" "SHSTK" > + > + # No error message, compilation succeeded so now run it via gdb. > + gdb_exit > + gdb_start > + gdb_reinitialize_dir $srcdir/$subdir > + gdb_load $obj > + if {![runto_main]} { > + return 0 There should be a call to "remote_file build delete $obj" here as well. > + } > + set shadow_stack_disabled_re "()" > + if {[istarget *-*-linux*]} { > + # Starting with v6.6., the Linux kernel supports CET shadow stack. > + # Dependent on the target we can see a nullptr or "" > + # when shadow stack is supported by HW and the linux kernel but Nit: Linux > + # not enabled for the current thread (for example due to a lack > + # of compiler or glibc support for -fcf-protection). > + set shadow_stack_disabled_re "$shadow_stack_disabled_re|(.*0x0)" > + } > diff --git a/gdb/x86-linux-nat.c b/gdb/x86-linux-nat.c > index d1fece717a7..5bbd4640e30 100644 > --- a/gdb/x86-linux-nat.c > +++ b/gdb/x86-linux-nat.c > @@ -41,6 +41,7 @@ > #include "nat/x86-linux.h" > #include "nat/x86-linux-dregs.h" > #include "nat/linux-ptrace.h" > +#include "x86-tdep.h" > #include "nat/x86-linux-tdesc.h" > > /* linux_nat_target::low_new_fork implementation. */ > @@ -97,11 +98,10 @@ const struct target_desc * > x86_linux_nat_target::read_description () > { > /* The x86_linux_tdesc_for_tid call only reads xcr0 the first time it is > - called. The mask is stored in XSTATE_BV_STORAGE and reused on > - subsequent calls. Note that GDB currently supports features for user > - state components only. However, once supervisor state components are > - supported in GDB XSTATE_BV_STORAGE will not be configured based on > - xcr0 only. */ > + called. Also it checks the enablement state of features which are > + not configured in xcr0, such as CET shadow stack. Once the supported The "not" above should be removed. > + features are identified, the XSTATE_BV_STORAGE value is configured > + accordingly and preserved for subsequent calls of this function. */ > static uint64_t xstate_bv_storage; > > if (inferior_ptid == null_ptid) > @@ -215,6 +215,46 @@ x86_linux_get_thread_area (pid_t pid, void *addr, unsigned int *base_addr) > } > > > +/* See x86-linux-nat.h. */ > + > +void > +x86_linux_fetch_ssp (regcache *regcache, const int tid) > +{ > + uint64_t ssp = 0x0; > + iovec iov {&ssp, sizeof (ssp)}; > + > + /* The shadow stack may be enabled and disabled at runtime. Reading the > + ssp might fail as shadow stack was not activated for the current > + thread. We don't want to show a warning but silently return. The > + register will be shown as unavailable for the user. */ > + if (ptrace (PTRACE_GETREGSET, tid, NT_X86_SHSTK, &iov) != 0) > + return; In case the ptrace fails and there is already an old value for ssp in regcache, shouldn't it be removed from it? > + > + x86_supply_ssp (regcache, ssp); > +} > + > +/* See x86-linux-nat.h. */ > + > +void > +x86_linux_store_ssp (const regcache *regcache, const int tid) > +{ > + uint64_t ssp = 0x0; > + iovec iov {&ssp, sizeof (ssp)}; > + x86_collect_ssp (regcache, ssp); > + > + /* Starting with v6.6., the Linux kernel supports CET shadow stack. > + Dependent on the target the ssp register can be unavailable or > + nullptr when shadow stack is supported by HW and the linux kernel but Nit: Linux > + not enabled for the current thread. In case of nullptr, GDB tries to > + restore the shadow stack pointer after an inferior call. The ptrace > + call with PTRACE_SETREGSET will fail here with errno ENODEV. We > + don't want to throw an error in this case but silently continue. */ > + errno = 0; > + if ((ptrace (PTRACE_SETREGSET, tid, NT_X86_SHSTK, &iov) != 0) > + && (errno != ENODEV)) > + perror_with_name (_("Failed to write pl3_ssp register")); Same question here: if the ptrace call fails shouldn't the ssp value in regcache be removed? > +} > + > void _initialize_x86_linux_nat (); > void > _initialize_x86_linux_nat () > diff --git a/gdb/x86-linux-nat.h b/gdb/x86-linux-nat.h > index 3c2241bb0b6..d5dc1908090 100644 > --- a/gdb/x86-linux-nat.h > +++ b/gdb/x86-linux-nat.h > @@ -92,4 +92,15 @@ struct x86_linux_nat_target : public x86_nat_target > extern ps_err_e x86_linux_get_thread_area (pid_t pid, void *addr, > unsigned int *base_addr); > > +/* Fetch the value of the shadow stack pointer register from process/thread > + TID and store it to GDB's register cache. */ > + > +extern void x86_linux_fetch_ssp (regcache *regcache, const int tid); > + > +/* Read the value of the shadow stack pointer from GDB's register cache > + and store it in the shadow stack pointer register of process/thread TID. > + Throw an error in case of failure. */ > + > +extern void x86_linux_store_ssp (const regcache *regcache, const int tid); > + > #endif /* GDB_X86_LINUX_NAT_H */ > diff --git a/gdb/x86-tdep.c b/gdb/x86-tdep.c > index e50b5fb9fa4..08fb0e8d82d 100644 > --- a/gdb/x86-tdep.c > +++ b/gdb/x86-tdep.c > @@ -17,10 +17,32 @@ > You should have received a copy of the GNU General Public License > along with this program. If not, see . */ > > +#include "defs.h" defs.h is now included in all GDB files via the gcc command line, and shouldn't be #included anymore. See commit 18d2988e5da8 ("gdb, gdbserver, gdbsupport: remove includes of early headers") and commit ab7daea3ad0d ("gdb, gdbserver, gdbsupport: include early header files with `-include`"). > +#include "i386-tdep.h" > #include "x86-tdep.h" > #include "symtab.h" -- Thiago