From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id LLfWJeelm2c0gB8AWB0awg (envelope-from ) for ; Thu, 30 Jan 2025 11:16:39 -0500 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=NRVLI1rS; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 8854D1E105; Thu, 30 Jan 2025 11:16:39 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-7.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H2 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 AC4451E08E for ; Thu, 30 Jan 2025 11:16:38 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 07D283858C60 for ; Thu, 30 Jan 2025 16:16:38 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 07D283858C60 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=NRVLI1rS Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id 6F15C3858D34 for ; Thu, 30 Jan 2025 16:14:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6F15C3858D34 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 6F15C3858D34 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1738253641; cv=none; b=PuOHPmbuCIhjtYOY2wP140bWlDXkMeUi7QYp4PPnuRvfskY1P30g+MqzuZr+NHN1BA8CKE/tU29ej+IX7e/YGEM+joNsYADQpAHPdignDLwsV/zDzd3hw4kNSX7TBR69C+bSiCFN2YmtztcD6ymoY2tfLYPuac+vuYDy4RlBBcc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1738253641; c=relaxed/simple; bh=z5POQb4V/ygQi3qmQdK2l9a7wZBVUl2Sdk33cvF0c6Q=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=HDhNRAycHdXKKA0pkFY5zZ0fUIue5GHYgEN2Kby//QsSlTm/rEpM+gpeq+0RrzPexUkTw1gBO2NlImk0LVL2TCxY5QVBu7YeEsGJlVxlN0zYVZzDVxLfJ2CBxNFKcba32VHvuRlE/k+qEh/GBgbnzIJFlO4AAiZom90FwK9Vh1Q= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1738253640; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3QDgKR1IoKvc3TmTiwEiQtfiWHeQaVPtFVp9hIgTgQY=; b=NRVLI1rSn4YF3o+rVZOgxzs176fseSasTbnwCccLx17qaSiZu3/yeNBu+J7GWF5tUyiMwC lJfE/anxlqMVabgY1K03x3L2OHcBv8eTqDJwfyATAGiqEH7kf3C5LJeSVVewI1LxYAyht0 GrZdm9Eva3KHN53MwpBLRURkYHOqDiA= Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-644-TXZ50N3kOA-z-0deAQnDlA-1; Thu, 30 Jan 2025 11:13:59 -0500 X-MC-Unique: TXZ50N3kOA-z-0deAQnDlA-1 X-Mimecast-MFC-AGG-ID: TXZ50N3kOA-z-0deAQnDlA Received: by mail-qk1-f197.google.com with SMTP id af79cd13be357-7b6ebe1ab63so223462285a.1 for ; Thu, 30 Jan 2025 08:13:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738253638; x=1738858438; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=3QDgKR1IoKvc3TmTiwEiQtfiWHeQaVPtFVp9hIgTgQY=; b=vphKBCMMFuCgt8RJX4KLg5MDZS406+i6gWEWu6FoUM+csD5u6SP9hJdSVonKqkYMo2 U3LmHptDlSln5aCo3gq8Qcej4BtWMG8wvwHh9xxM+wS0GPjmRJGJ0ZCwJo6XweZK0FK4 7yY/jE/PhPLMZj8fNxcBFldLnWC/T0ltbHMbxtTaBcTk/yzZTek4e6Xa/rtMeMuJePK6 ypZL63ohTRPeF3LYmx041VT0qX3T0wKUzN8XvTL7onRgMYjwi5pbJAx+jge0CXKECI0O 2CgzwCaGNovmRRtXrlV/Y81hssXjUyyjdagXBO6peRxKksVp4FTedNd5Ym4nQNjQfrLW u56Q== X-Forwarded-Encrypted: i=1; AJvYcCWqBoOvxjw9L4KDsgTm0w908KQUZ7V5EHxIGv8fEXgPbXbZSGDJYXpZXD8EhanCu+eKNCy8aehcblq6jQ==@sourceware.org X-Gm-Message-State: AOJu0Yykdip2zxLd9CXCoYUod+FjAepMIcyJAsS7+X0++2jKsb6miyCO cgl/V9nGWi7OS3+e2fknU8yn2xpi5CwZvBnxXQZ2aEaWP1GGaz4GonQ4yrLnhh9FVoYlOQuHvhz GejV/XFVLdK95QoeP5ftfqwTT92Jem8cn/32b4y3zstndbsXiGoSxzeY5z1Eb+8uuZ3I= X-Gm-Gg: ASbGncuLcIj9JQmz/aQRoYSMEH3JD3rtVuq23QMbkuTIzi2qNSObmIDwulYMcHCAJaZ QkrEFzHhxXxfe3hfU63VHzodBBN4lHx426xaxt7yygE9J8G1hvKaPStFvAT9IuezN16Ppsv5SWg yYc1Y+OSjX65dn6ahWH3tgzuJ2qC+M1ctN1NL7nvIcIiEZuVgZz0bCulhKNWdNh67BEaKtw/8hd egqFgWgpBvTfTp4ckK1FTZEE2VIGf71hZ5oSEBmyken8NBGQIrMNY+az14MnrMwowTRZxQ5IpQa 1W727/GMzfctmTpT X-Received: by 2002:a05:620a:608a:b0:7b1:4a48:56bb with SMTP id af79cd13be357-7bffcd9b597mr1350799385a.56.1738253638452; Thu, 30 Jan 2025 08:13:58 -0800 (PST) X-Google-Smtp-Source: AGHT+IHiub2ZKeQv6VN8yTfhOB1f+/7hmWwqmRdv3y33iP1X4Bom4B5U7nBuwPeqxxjYrl9ZQzCcyQ== X-Received: by 2002:a05:620a:608a:b0:7b1:4a48:56bb with SMTP id af79cd13be357-7bffcd9b597mr1350797385a.56.1738253638188; Thu, 30 Jan 2025 08:13:58 -0800 (PST) Received: from ?IPV6:2804:14d:8084:9a69::1002? ([2804:14d:8084:9a69::1002]) by smtp.gmail.com with ESMTPSA id af79cd13be357-7c00a8bbdc5sm87574785a.20.2025.01.30.08.13.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 30 Jan 2025 08:13:57 -0800 (PST) Message-ID: <6051664d-7fbf-4d0b-9ac6-d194a34b292c@redhat.com> Date: Thu, 30 Jan 2025 13:13:55 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 08/12] gdb: Handle shadow stack pointer register unwinding for amd64 linux. To: "Schimpe, Christina" , "gdb-patches@sourceware.org" References: <20241220200501.324191-1-christina.schimpe@intel.com> <20241220200501.324191-9-christina.schimpe@intel.com> <4f873c4a-a4ba-451f-8908-bc40ab93c43a@redhat.com> From: Guinevere Larsen In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: sZR-TBh0-6wFSUAXh3ZApWl2bCLEBaDt47JxAglHLWw_1738253638 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 On 1/30/25 1:11 PM, Schimpe, Christina wrote: >> -----Original Message----- >> From: Guinevere Larsen >> Sent: Thursday, January 30, 2025 3:29 PM >> To: Schimpe, Christina ; gdb- >> patches@sourceware.org >> Subject: Re: [PATCH 08/12] gdb: Handle shadow stack pointer register unwinding >> for amd64 linux. >> >> On 12/20/24 5:04 PM, Schimpe, Christina wrote: >>> Unwind the $pl3_ssp register. >>> We now have an updated value for the shadow stack pointer when moving >>> up or down the frame level. Note that $pl3_ssp can become unavailable >>> when moving to a frame before the shadow stack enablement. In the >>> example below, shadow stack is enabled in the function 'call1'. Thus, >>> when moving to a frame level above the function, $pl3_ssp will become >>> unavaiable. >>> Following the restriction of the linux kernel, implement the unwinding >>> for amd64 linux only. >>> >>> Before this patch: >>> ~~~ >>> Breakpoint 1, call2 (j=3) at sample.c:44 >>> 44 return 42; >>> (gdb) p $pl3_ssp >>> $1 = (void *) 0x7ffff79ffff8 >>> (gdb) up >>> 55 call2 (3); >>> (gdb) p $pl3_ssp >>> $2 = (void *) 0x7ffff79ffff8 >>> (gdb) up >>> 68 call1 (43); >>> (gdb) p $pl3_ssp >>> $3 = (void *) 0x7ffff79ffff8 >>> ~~~ >>> >>> After this patch: >>> ~~~ >>> Breakpoint 1, call2 (j=3) at sample.c:44 >>> 44 return 42; >>> (gdb) p $pl3_ssp >>> $1 = (void *) 0x7ffff79ffff8 >>> (gdb) up >>> 55 call2 (3); >>> (gdb) p $pl3_ssp >>> $2 = (void *) 0x7ffff7a00000 >>> (gdb) up >>> 68 call1 (43i); >>> (gdb) p $pl3_ssp >>> $3 = >>> ~~~ >>> >>> As we now have an updated value for each selected frame, the return >>> command is now enabled for shadow stack enabled programs, too. >>> >>> We therefore add a test for the return command and shadow stack >>> support, and for an updated shadow stack pointer after a frame level change. >>> --- >>> gdb/amd64-linux-tdep.c | 69 +++++++++++++++ >>> gdb/linux-tdep.c | 47 ++++++++++ >>> gdb/linux-tdep.h | 7 ++ >>> .../gdb.arch/amd64-shadow-stack-cmds.exp | 88 +++++++++++++++++++ >>> gdb/testsuite/gdb.arch/amd64-shadow-stack.c | 13 +++ >>> 5 files changed, 224 insertions(+) >>> create mode 100644 >>> gdb/testsuite/gdb.arch/amd64-shadow-stack-cmds.exp >>> >>> diff --git a/gdb/amd64-linux-tdep.c b/gdb/amd64-linux-tdep.c index >>> 95f643b1217..895feac85e8 100644 >>> --- a/gdb/amd64-linux-tdep.c >>> +++ b/gdb/amd64-linux-tdep.c >>> @@ -45,6 +45,8 @@ >>> #include "arch/amd64-linux-tdesc.h" >>> #include "inferior.h" >>> #include "x86-tdep.h" >>> +#include "dwarf2/frame.h" >>> +#include "frame-unwind.h" >>> >>> /* The syscall's XML filename for i386. */ >>> #define XML_SYSCALL_FILENAME_AMD64 "syscalls/amd64-linux.xml" >>> @@ -1873,6 +1875,72 @@ >> amd64_linux_remove_non_address_bits_watchpoint (gdbarch *gdbarch, >>> return (addr & amd64_linux_lam_untag_mask ()); >>> } >>> >>> +static value * >>> +amd64_linux_dwarf2_prev_ssp (const frame_info_ptr &this_frame, >>> + void **this_cache, int regnum) { >>> + value *v = frame_unwind_got_register (this_frame, regnum, regnum); >>> + gdb_assert (v != nullptr); >>> + >>> + gdbarch *gdbarch = get_frame_arch (this_frame); >>> + >>> + if (v->entirely_available () && !v->optimized_out ()) >>> + { >>> + int size = register_size (gdbarch, regnum); >>> + bfd_endian byte_order = gdbarch_byte_order (gdbarch); >>> + CORE_ADDR ssp = extract_unsigned_integer (v->contents_all ().data (), >>> + size, byte_order); >>> + >>> + /* Starting with v6.6., the Linux kernel supports CET shadow stack. >>> + Using /proc/PID/smaps we can only check if the current shadow >>> + stack pointer SSP points to shadow stack memory. Only if this is >>> + the case a valid previous shadow stack pointer can be >>> + calculated. */ >>> + std::pair range; >>> + if (linux_address_in_shadow_stack_mem_range (ssp, &range)) >>> + { >>> + /* The shadow stack grows downwards. To compute the previous >>> + shadow stack pointer, we need to increment SSP. >>> + For x32 the shadow stack elements are still 64-bit aligned. >>> + Thus, we cannot use gdbarch_addr_bit to compute the new stack >>> + pointer. */ >>> + const bfd_arch_info *binfo = gdbarch_bfd_arch_info (gdbarch); >>> + const int bytes_per_word >>> + = (binfo->bits_per_word / binfo->bits_per_byte); >> In patch 10 of this series, you introduce >> amd64_linux_shadow_stack_element_size_aligned to simplify this calculation. is >> there any reason you didn't introduce it here? > Thanks a lot for looking at this. > > The reason is that at this state of the series I only had one occurrence of this > particular code line and its comment. To avoid duplication I decided to make a > small function for it in patch 10, but before it seemed to introduce more > overhead. Would that make sense to you? > This makes sense, but in that case I think it's better to just create this function at this point, so that code doesn't get created and deleted unnecessarily. -- Cheers, Guinevere Larsen She/Her/Hers