From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id GDg6Jj99JmmwiTAAWB0awg (envelope-from ) for ; Tue, 25 Nov 2025 23:08:31 -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=s/BnqKe+; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 86ED11E0B3; Tue, 25 Nov 2025 23:08:31 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.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,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 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 F3A671E048 for ; Tue, 25 Nov 2025 23:08:28 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 0FA6D3858C98 for ; Wed, 26 Nov 2025 04:08:28 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0FA6D3858C98 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=s/BnqKe+ Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) by sourceware.org (Postfix) with ESMTPS id 1FC303858D20 for ; Wed, 26 Nov 2025 04:07:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1FC303858D20 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 1FC303858D20 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::430 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1764130042; cv=none; b=QTxgoBTkxuCeEqoFhn0z8+0YR0WSAVSmubHdpwixXmZVbxnKjMAT/1AsA0P13y8NB8J4YrSjMOqfat6CUXRI5ypgiyWuTBjsTSAJLsLzsHE8FtY6xeAsMciqsxjai0xmDp5QqPeF95Gh+NUuoqH45YzC9Fnb5ErcyjVS6Uw0ByI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1764130042; c=relaxed/simple; bh=7h/TfIIsGtbrGoKkP9iGdtkyXAJFjDUqiMHAA5yaC4k=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=HM7uMnV9y71VmfQ2P4+fZUPBLSBQmsidCEGASlob0+pMKi8yGFnDheQLvuwEDWSOSjSGQrv+/UegTfbSAZyLy4PCwsb2esCfe4rnfI0C86DVmEceg5GR4iC94dIRwAdDbV/oDa3y9PdUriZEgDr8fRKlRsNKSdimdqWYIRKHMs8= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1FC303858D20 Received: by mail-pf1-x430.google.com with SMTP id d2e1a72fcca58-7b89c1ce9easo7368951b3a.2 for ; Tue, 25 Nov 2025 20:07:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1764130040; x=1764734840; darn=sourceware.org; h=content-transfer-encoding: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=K5kGAk+zWcMr4EZajf6mSvPkuw90NtLPhd5qqUNx8Sg=; b=s/BnqKe+VmWFjFKBEXwfmoSiKC11UsZ3a+03zcRYmLlMnRiEBL+e2FFVzYpS8Wk6sc o+EFufYeACTNSZcr9qkbu+71NUeawseI+jlPXPyQaY/cZq/0Qfp1Ltm0FCn/5gag2aiz YIZsYyr73NNCYaTJdD4eQyeegHKNGnPJ2A1HDnHX3ZsY6vEOgfcLCpYPXbUTr/vVe//S fe3V2nKq1B2MQcyEVZr2kqYepdGrKuoPIGBTq9bcQCu4GHTEZYEKngRfDjAkQ6kaGBWm rJrtwlH3bxILqlcJdO2wGu4RQMC9oo5EHkx7OknjTFWFMX7CSV6SFFHq6Pfsiqq0tEgb Lb1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764130040; x=1764734840; h=content-transfer-encoding:mime-version:message-id:date:user-agent :references:in-reply-to:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=K5kGAk+zWcMr4EZajf6mSvPkuw90NtLPhd5qqUNx8Sg=; b=I98ChrLjCbXulLwe1buVCB2DCesXyiV6K+hU6UFxFlFngvOwt2m8jIPGpvmQdYi2PT d9zNSXhEF9TGW6y9VKNX8qporC34uOxGZin5qqIys+u5njInARgOqxJbmwyAUfig11HS Tv/BnVUj1FDNXNGqjjRhT+KhFb72SYcC8bwoQrWj5ZqqIpETM9pvpF7w9QdaK1o6Xeng m4O+6EwAZb5QxUJ3rMthyxA7TN5yZi3CqXlTgmnPpMVgiQnWvW74D4Sg54JBDn8lMHLR IDBCQUxGfhZ96XjLeUH+2PAEsFtEOvC6GZUs2Sv1tuZArTMUv0LiZ4PyV190NImGJyfb TDDA== X-Gm-Message-State: AOJu0Yxr+jrQ4s+Xj+g/E/JwZ2Mm355E7juhun6bObsnzQTsOAwd6w4/ zUiZUNrNp7VHX919jOGzhr6cZyFob+UH0d+KGXRbF7N2y+cLNj/uMvunpw3fNchcz9E= X-Gm-Gg: ASbGncueYgG0k5EuWMDmC8OPiN1qW1nGDmhBb+YQ2F092/9IDIj2A//0yCt7zuOc1uX h63GgDrAmx6mf5qSK0jX13tCQmXL1wB0xEx7UHeY0heQ7rly3L6JaJTCRFuF/ZN86AYuVqBvNrb 4H8eZqXyd4CbGpWTibbcTMZEC8BZSnj8Z21AnGR+bx4PqbrYthwvT/IU9GbYM77Iv3RKVCPnwuO cfO5zHPbi918JH1L26HQF7jbXPWaDX51aoK2r5JYQHZyod0FNjCjbmtTfMWWImCZe6Af7UzjEka fwMqHTt0akQXnNSjlRS74VvbTxDaAa9tkRwW5H763FD+Tjar9zSX2d96ssPr6ISJbgcKpQhqT3W te3dROfWiSjfiJpxCMw7tBskEjkKEuZidnbUDoYi6nL++EBQC1t7MwXFBRmqwG2Ch9pJJXOo91m EHP9IZtObyHQZPxp8Hg2vD X-Google-Smtp-Source: AGHT+IHV50Bt+R/mCxe1qioKSOa2hLMawmBk4SyvtlZn2HNdB/yu7aRBPa5Hs1iiMOjYofrd5J35gw== X-Received: by 2002:a05:7022:4419:b0:119:e569:f25f with SMTP id a92af1059eb24-11c9d70b0d1mr13211020c88.8.1764130040011; Tue, 25 Nov 2025 20:07:20 -0800 (PST) Received: from localhost ([2804:14d:7e39:8083:2b62:e85c:5936:d298]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-11cc631c236sm19182077c88.7.2025.11.25.20.07.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 Nov 2025 20:07:19 -0800 (PST) From: Thiago Jung Bauermann To: "Schimpe, Christina" Cc: "gdb-patches@sourceware.org" Subject: Re: [PATCH 6/9] gdb: Implement 'bt shadow' to print the shadow stack backtrace. In-Reply-To: (Christina Schimpe's message of "Mon, 17 Nov 2025 20:14:52 +0000") References: <20250923111842.4091694-1-christina.schimpe@intel.com> <20250923111842.4091694-7-christina.schimpe@intel.com> <874irfsoqc.fsf@linaro.org> User-Agent: mu4e 1.12.13; emacs 30.2 Date: Wed, 26 Nov 2025 01:07:16 -0300 Message-ID: <877bvdsah7.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: > Hi Thiago, > > Thanks for taking the time to provide this review=E2=80=94I really apprec= iate your detailed input! You're most welcome. Thank you for pushing the shadow stack feature forward! > I=E2=80=99ve implemented part of your feedback, and there are still a few= open points I=E2=80=99d like to clarify. > I hope I didn=E2=80=99t miss any of your comments, as the review has beco= me quite comprehensive. Indeed, the review ended up more detailed than I anticipated because I'm using the review process to also develop the AArch64 side. This made me dig into the code quite a bit. > Please find my responses and open questions below. Looking forward to you= r thoughts! Thanks! >> -----Original Message----- >> From: Thiago Jung Bauermann >> Sent: Freitag, 31. Oktober 2025 05:02 >> To: Schimpe, Christina >> Cc: gdb-patches@sourceware.org >> Subject: Re: [PATCH 6/9] gdb: Implement 'bt shadow' to print the shadow >> stack backtrace. >>=20 >> Christina Schimpe writes: >>=20 >> > Example for the output of 'bt shadow' on amd64 linux: >> > ~~ >> > (gdb) bt shadow >> > /#0 0x000000000040111f in call1 at amd64-shadow-stack.c:14 >> > /#1 0x000000000040112f in main at amd64-shadow-stack.c:21 >> > /#2 0x00007ffff7c3fe70 in __libc_start_call_main at >> > ../sysdeps/nptl/libc_start_call_main.h:58 >> > /#3 0x00007ffff7c3ff20 in __libc_start_main_impl at >> > ../csu/libc-start.c:128 >> > /#4 0x0000000000401045 in _start >> > ~~ >>=20 >> Here's an example output in my aarch64-linux test VM: >>=20 >> (gdb) bt shadow >> #0 0x0000aaaaaaaa08ac in call2 at aarch64-gcs-return.c:65 >> #1 0x0000aaaaaaaa08c0 in call1 at aarch64-gcs-return.c:71 >> #2 0x0000aaaaaaaa09d4 in main at aarch64-gcs-return.c:110 >> #3 0x0000000000000000 in ?? >>=20 >> And here is the regular backtrace at the same point: >>=20 >> (gdb) bt >> #0 call3 () at aarch64-gcs-return.c:58 >> #1 0x0000aaaaaaaa08ac in call2 () at aarch64-gcs-return.c:64 >> #2 0x0000aaaaaaaa08c0 in call1 () at aarch64-gcs-return.c:70 >> #3 0x0000aaaaaaaa09d4 in main () at aarch64-gcs-return.c:107 >>=20 >> I have a few comments on this output, at least as it is appears for GCS.= I'm >> assuming x86 shadow stack output is similar: >>=20 >> 1. The first thing that I notice is that the number of the frames don't = match >> between the regular stack and the shadow stack: frame 0 in the regular s= tack >> doesn't exist in the shadow stack, regular frame 1 is shadow frame 0, an= d so >> on. >>=20 >> I think this is confusing. It makes sense that frame 0 doesn't appear in= the >> shadow stack backtrace because there really isn't an entry for it in the >> shadow stack, but I think the shadow entries should start with number 1,= to >> be consistent. > > Mh, it's probably better to align, I agree. > I'll go with starting frame #1 in the v2, and add a comment about that in= the > commit message. > >> 2. The line numbers corresponding to the return addresses don't match >> between the regular backtrace and the shadow backtrace, even though the >> return addresses are the same. I would say this is a bug. Perhaps there = can be >> a test making sure they match, if it's not too complicated? > > The reason for that is explained in a comment in do_print_shadow_stack_fr= ame_info: > > /* In contrast to find_frame_sal which is used for the ordinary backtra= ce > command, we always want to print the line that is actually referred > to by the address in the linetable. That's why we always pass 0 here > as second argument. */ I don't understand why we want to always print the line that is actually referred to by the address in the linetable. find_frame_sal has this comment: /* If FRAME is not the innermost frame, that normally means that FRAME->pc points at the return instruction (which is *after* the call instruction), and we want to get the line containing the call (because the call is where the user thinks the program is). Doesn't that also apply to the addresses in the shadow stack? > Do you think we should align this with the behavior of the ordinary backt= race command > here as well? I think so, but maybe there's something I'm not considering. > I=E2=80=99m not entirely sure if that approach might be too straightforwa= rd, since we can=E2=80=99t simply > call the get_frame_address_in_block function as the ordinary bt command d= oes when > invoking it from find_frame_sal. >From what I understand of the big comment in get_frame_address_in_block, we can create an equivalent function for shadow stack frames: it should return an adjusted PC for frames corresponding to normal function calls, which are all except: 1. sentinel frame 2. signal frame 3. dummy frame=20 These are easy to recognise (or in the case of 3, can be made easy to recognise) in the shadow stack: 1. Since the shadow stack doesn't have frame #0, this_frame is never the sentinel one. And next_frame will be the "sentinel" if this_frame is the first one in the shadow stack. 2. The Linux kernel on both AArch64 and Intel puts a marker in the shadow stack when a signal is handled, so we can look for it in the shadow stack to recognize the signal frame. 3. We can change GDB to also put a marker in the shadow stack when it does an inferior function call, and look for it in the shadow stack. >> > +/* Return true, if PC is in the middle of a statement. Note that in = the >> > + middle of a statement PC range includes sal.end (SAL.PC, SAL.END]. >> > + Return false, if >> > + - SAL.IS_STMT is false >> > + - there is no location information associated with this SAL, which >> > + could happen in case of inlined functions >> > + - PC is not in the range (SAL.PC, SAL.END]. >> > + This function is similar to stack.c:frame_show_address but is used >> > + to determine if we are in the middle of a statement only, not to d= ecide >> > + if we should print a frame's address. */ >> > + >> > +static bool >> > +pc_in_middle_of_statement (CORE_ADDR pc, symtab_and_line sal) { >> > + if (sal.is_stmt =3D=3D false) >> > + return false; >> > + >> > + /* If there is a line number, but no PC, then there is no location >> > + information associated with this sal. The only way that should >> > + happen is for the call sites of inlined functions (SAL comes from >> > + find_frame_sal). Otherwise, we would have some PC range if the >>=20 >> In the case of stack.c:frame_show_address, SAL comes from find_frame_sal, >> but in this case it comes from find_pc_line, right? > > Yes, it comes from find_sal_for_pc (when rebased on latest master, find_p= c_line was renamed). > >> Does the comment still apply in this case? > > Good question, I remember I stumbled over this a couple of times when imp= lementing this. > In any case, the comment needs to be corrected to "(SAL comes from find_s= al_for_pc)." > If we need this check, I am not sure. In my experiments with inlined func= tions I could > not reproduce that scenario. But I kept it, to be safe. >From my reading of find_pc_line / find_sal_for_pc, it doesn't return a sal with line number but no PC. But I'm not very familiar with this part of the code. But I don't mind keeping this check (with an adjusted comment, as you mention). >> > + SAL came from a line table. However, as we don't have a frame f= or >> > + this function we cannot assert (in contrast to >> > + frame_show_address). */ >> > + if (sal.line !=3D 0 && sal.pc =3D=3D 0 && sal.end =3D=3D 0) >> > + return false; >> > + >> > + return pc > sal.pc && pc <=3D sal.end; >> > +} >> > +/* Extract a char array which can be used for printing a reasonable >> > + error message for REASON. Note that in case REASON has the value >> > + NO_ERROR the returned array is empty. */ >> > + >> > +static const char * >> > +ssp_unwind_stop_reason_to_err_string (ssp_unwind_stop_reason reason) >> > +{ >> > + switch (reason) >> > + { >> > + case ssp_unwind_stop_reason::no_error: >> > + return _(""); >>=20 >> The empty string doesn't need to be translated > > True. > >> All callers make sure that reason isn't no_error, so perhaps just remove= this case? > > I am not sure, if I can follow completely. You mean I should remove the c= ase and replace > gdb_assert_not_reached ("invalid reason"); with return "" ? I mean just remove this case from the switch. Then this function will assert whenever reason !=3D ssp_unwind_stop_reason::memory_read_error. >> > + case ssp_unwind_stop_reason::memory_read_error: >> > + return _("shadow stack memory read failure"); >> > + } >> > + >> > + gdb_assert_not_reached ("invalid reason"); >> > +} >> > +/* If possible, return a shadow stack frame info which is COUNT elem= ents >> > + above the bottom of the shadow stack. FRAME should point to the = top >> > + of the shadow stack. RANGE is the shadow stack memory range >> > + [start_address, end_address) corresponding to FRAME's shadow stack >> > + pointer. If COUNT is bigger than the number of elements on the s= hadow >> > + stack, return FRAME. >>=20 >> Here is another place where I find "above/bottom/top" confusing, since >> stacks can grow up or grow down (as pointed out in the next comment in t= his >> function), and these terms mean different things in each case. > > Yes, the comment is now=20 > "...above the outermost (oldest) element of the shadow stack." > > I hope this is more straight-forward. There's still "above" and "top". A suggestion: "If possible, return a shadow stack frame info which is COUNT elements newer than the outermost (oldest) element of the shadow stack. FRAME should point to the newest element of the shadow stack..." >> > + In case of failure, assign an appropriate ssp_unwind_stop_reason = in >> > + FRAME->UNWIND_STOP_REASON. */ >> > + >> > +static std::optional >> > +get_trailing_outermost_shadow_stack_frame_info >> > + (gdbarch *gdbarch, const std::pair range, >> > + const ULONGEST count, shadow_stack_frame_info &frame) { >> > + /* Compute the number of bytes on the shadow stack, starting at >> > + FRAME->SSP, which depends on the direction the shadow stack >> > + grows. */ >> > + const int element_size >> > + =3D gdbarch_shadow_stack_element_size_aligned (gdbarch); >> > + const unsigned long shadow_stack_bytes >> > + =3D (gdbarch_stack_grows_down (gdbarch)) >>=20 >> The parentheses around the function call are superfluous. > > Fixed. > >> > + ? range.second - frame.ssp : frame.ssp - range.first + >> > + element_size; >> > + >> > + gdb_assert ((shadow_stack_bytes % element_size) =3D=3D 0); const >> > + unsigned long shadow_stack_size >> > + =3D shadow_stack_bytes / element_size; >>=20 >> This line fits 80 columns and doesn't need to be broken. >>=20 >> > + const long level =3D shadow_stack_size - count; >>=20 >> In a comment further below you mention that level is 0-based, but doesn't >> this expression mean that it's 1-based? Perhaps it's missing a >> "- 1" term? >> Also, this doesn't work for GCS because it assumes all elements in the s= tack >> are return addresses. In GCS, the oldest element is a 0 entry >> The 0 entry is why this patch requires AArch64 to implement its own gdba= rch >> top_addr_empty_shadow_stack hook. > > There is clearly an issue with this function. But I am not sure if I can= follow here. > Shouldn't the issue be fixed when passing LEVEL instead of COUNT, as poin= ted out by you below? Passing level instead of count is necessary but not sufficient. The function's documentation comment says that it returns "a shadow stack frame info which is COUNT elements newer than the outermost (oldest) element of the shadow stack". One example: Suppose that the shadow stack has 5 elements and count is 2. Then level as calculated by your patch is 3 (5 - 2). So frame.ssp will be adjusted by 3 elements by the call to update_shadow_stack_pointer further below. This is wrong though, because it makes new_ssp point to 1 element newer than the oldest element of the shadow stack. If level is calculated instead as level =3D shadow_stack_size - count - 1 then in this example it will be 2 and new_ssp will point to 2 elements newer than the oldest element of the shadow stack, which matches the documentation comment. But that still doesn't work for AArch64, because every shadow stack there has an extra element at the beginning which also needs to be discounted, so in this case it should be: const long level =3D shadow_stack_size - count - 2; But then it's wrong for Intel. > And if not, do you have an idea how we can fix this?=20 I suggest adding a gdbarch method which given RANGE, returns how many entries there are in the shadow stack. And to calculate level as: const long level =3D shadow_stack_size - count - 1; Where count is the result of the gdbarch hook. >> Finally, not a concern for userspace support (and thus this patch >> series) but for OS and hypervisor software there's another kind of GCS e= ntry >> which is the exception return record that is put on the stack when an >> exception is taken. That entry is 32 bytes in size. I mention this just= to >> illustrate that calculating the number of entries in the stack can be no= n- >> trivial. > > Oh, I see. Isn't that already a problem with the current unwinding of the= shadow > stack pointer for GCS? How would you fix it there ? It's not a problem for now because GCS support is only implemented for Linux userspace inferiors. It's a bridge to be crossed in the future. :) I just mentioned this case to illustrate that assuming that all entries in the shadow stack have the same size is fragile. But for now it's good enough, so perhaps I shouldn't have mentioned it. >> Not sure how to account for these variations in generic code. Maybe add a >> new gdbarch method for returning the number of entries in the shadow >> stack? > > To implement this, I believe we have two possible approaches: > > (1) Assume we can determine the number of elements without unwinding each= frame (as it is > currently the case). In this scenario, we could introduce a generic gdbar= ch hook to > retrieve the number of elements for architectures that require a differen= t calculation. > > (2) Unwind each shadow stack frame to obtain the trailing outermost frame= , similar to how the > normal backtrace works. > > Do you see any additional options? No, I can also only think of these. > Alternatively, we could keep the current approach for now (without the gd= barch hook, based on > the existing calculation) and only revise the implementation if other OS = or hypervisor software > require different logic=E2=80=94once we have the ability to test those ca= ses properly. > What are your thoughts? The current approach isn't feasible because level needs to be calculated in one way for Intel, and a different way for AArch64. I suggest the gdbarch hook option. >> > + >> > + /* COUNT exceeds the number of elements on the shadow stack. Retur= n the >> > + starting shadow stack frame info FRAME. */ >> > + if (level <=3D 0) >> > + return std::optional (frame); >> > + >> > + CORE_ADDR new_ssp =3D update_shadow_stack_pointer >> > + (gdbarch, frame.ssp, count, ssp_update_direction::bottom); >>=20 >> Shouldn't update_shadow_stack_pointer be called with 'level' rather than >> 'count' as argument? > > Ah, you=E2=80=99re absolutely right. I=E2=80=99m certain this worked at s= ome point before I posted it. > I=E2=80=99m not sure how this issue slipped in=E2=80=94and even more conc= erning that my tests didn=E2=80=99t catch it. > >> > + if (gdbarch_stack_grows_down (gdbarch)) >> > + gdb_assert (new_ssp < range.second); else >> > + gdb_assert (new_ssp >=3D range.first); >> > + >> > + CORE_ADDR new_value; >> > + if (!read_shadow_stack_memory (gdbarch, new_ssp, &new_value, >> > + &frame.unwind_stop_reason)) >> > + return {}; >> > + >> > + return std::optional >> > + ({new_ssp, new_value, (ULONGEST) level, >> > + ssp_unwind_stop_reason::no_error}); >>=20 >> This line causes a compilation error in arm-linux-gnueabihf, and I suppo= se >> other 32-bit targets as well: >>=20 >> /home/bauermann/src/binutils-gdb/gdb/shadow-stack.c:471:27: error: >> narrowing conversion of =E2=80=98(ULONGEST)((long int)level)=E2=80=99 fr= om =E2=80=98ULONGEST=E2=80=99 {aka >> =E2=80=98long long unsigned int=E2=80=99} to =E2=80=98long unsigned int= =E2=80=99 [-Werror=3Dnarrowing] >> 471 | ({new_ssp, new_value, (ULONGEST) level, >> ssp_unwind_stop_reason::no_error}); >> | ^~~~~~~~~~~~~~~~ >>=20 >> Also, it fits 80 columns and doesn't need to be broken. > > Thanks, casting it as follows: > (unsigned long) level > should hopefully fix this. And then I will have more than 80 characters. Ok. >> > +} >> > + >> > +std::optional >> > +shadow_stack_frame_info::unwind_prev_shadow_stack_frame_info >> > + (gdbarch *gdbarch, std::pair range) { >> > + /* If the user's backtrace limit has been exceeded, stop. We must >> > + add two to the current level; one of those accounts for >> > + backtrace_limit being 1-based and the level being 0-based, and t= he >> > + other accounts for the level of the new frame instead of the lev= el >> > + of the current frame. */ >> > + if (this->level + 2 > user_set_backtrace_options.backtrace_limit) >> > + return {}; >> > + >> > + CORE_ADDR new_ssp >> > + =3D update_shadow_stack_pointer (gdbarch, this->ssp, 1, >> > + ssp_update_direction::bottom); >> > + >> > + if (gdbarch_stack_grows_down (gdbarch)) >>=20 >> To make this work for GCS, I had to add another if statement before the = one >> above, to handle the case where new_ssp is at the initial 0 value: >>=20 >> if (gdbarch_top_addr_empty_shadow_stack_p (gdbarch) >> && gdbarch_top_addr_empty_shadow_stack (gdbarch, new_ssp, range)) >> return {}; >> else if (gdbarch_stack_grows_down (gdbarch)) >> =E2=8B=AE >>=20 >> Otherwise "bt shadow" will print the 0 entry: >>=20 >> (gdb) bt shadow >> #0 0x0000aaaaaaaa08ac in call2 at aarch64-gcs-return.c:65 >> #1 0x0000aaaaaaaa08c0 in call1 at aarch64-gcs-return.c:71 >> #2 0x0000aaaaaaaa09d4 in main at aarch64-gcs-return.c:110 >> #3 0x0000000000000000 in ?? > > Yes, I missed that. Thanks. > >> > + { >> > + /* The shadow stack grows downwards. */ >> > + if (new_ssp >=3D range.second) >> > + { >> > + /* We reached the bottom of the shadow stack. */ >>=20 >> In this case, we reached the top actually. This is why I find it confusi= ng to use >> bottom/top as if it where agnostic to whether the stack grows up or down= ... > > In my vision this is to "bottom" actually, if you look at this from a "st= ack" perspective. > But I changed this to "We reached the outermost element". Thanks. >> > + /* Check if START_SSP points to a shadow stack memory range and use >> > + the returned range to determine when to stop unwinding. >> > + Note that a shadow stack memory range can change, due to shadow = stack >> > + switches for instance on x86 for an inter-privilege far call or = when >> > + calling an interrupt/exception handler at a higher privilege lev= el. >> > + Shadow stack for userspace is supported for amd64 linux starting= with >> > + Linux kernel v6.6. However, shadow stack switches are not suppo= rted >> > + due to missing kernel space support. We therefore implement this >> > + command without support for shadow stack switches for now. */ >>=20 >> Hm, I'm not sure if aarch64-linux supports GCS switching. The kernel's g= cs.rst >> documentation says: >>=20 >> * The architecture provides instructions for switching between guarded >> control stacks with checks to ensure that the new stack is a valid >> target for switching. >>=20 >> And a comment in AArch64's implementation of the map_shadow_stack >> syscall says: >>=20 >> /* >> * Put a cap token at the end of the allocated region so it >> * can be switched to. >> */ >>=20 >> But I don't see anything positively mention that it's supported. >> I assume so, but I'll have to confirm. If that is the case, later I will= submit a >> patch with any necessary changes. > > Ok, so keeping the current comment is fine for you? Yes. Sorry, that was another confusing digression from me. >> > + std::pair range; >> > + if (!gdbarch_address_in_shadow_stack_memory_range (gdbarch, *start_= ssp, >> > + &range)) >>=20 >> Shouldn't this if condition also check >> gdbarch_top_addr_empty_shadow_stack? > > For x86 this logic is fine, but I assume for GCS this does not work for e= mpty > shadow stacks? Indeed, we need the extra check for GCS. >> > + { >> > + /* If the current shadow stack pointer does not point to shadow >> > + stack memory, the shadow stack is empty. */ >> > + gdb_printf (_("The shadow stack is empty.\n")); >> > + return; >> > + } >> > + >> > + /* Extract the first shadow stack frame info (level 0). */ >> > + ssp_unwind_stop_reason reason =3D ssp_unwind_stop_reason::no_error; >> > + std::optional current; >> > + CORE_ADDR new_value; >> > + if (read_shadow_stack_memory (gdbarch, *start_ssp, &new_value, &rea= son)) >> > + current =3D {*start_ssp, new_value, 0, >> > + ssp_unwind_stop_reason::no_error}; >>=20 >> This line fits in 80 columns and doesn't need to be broken. > > Yes, I changed that. > >> > + >> > + std::optional trailing =3D current; >> > + >> > + LONGEST count =3D -1; >> > + if (current.has_value () && count_exp !=3D nullptr) >> > + { >> > + count =3D parse_and_eval_long (count_exp); >> > + /* If count is negative, update trailing with the shadow stack = frame >> > + info from which we should start printing. */ >>=20 >> Actually, trailing will be the frame above the one from which we should = start >> printing. For example, if count is -3 >> get_trailing_outermost_shadow_stack_frame_info will return the frame >> "which is COUNT elements above the bottom of the shadow stack", which in >> this case is the 4th frame counting from the oldest frame. But we need to >> start printing from the 3rd oldest frame ... > >> > + if (count < 0) >> > + { >> > + trailing =3D get_trailing_outermost_shadow_stack_frame_info >> > + (gdbarch, range, std::abs (count), *current); >>=20 >> ... so this call should pass std::abs (count) - 1 as argument. > > Hm, I am not sure if I can follow. With the fix for passing level instead > of count my current output looks as follow: >=20=20=20=20=20=20=20=20 > ~~~ > Breakpoint 1, call2 () at /tmp/amd64-shadow-stack.c:21 > 21 return 42; /* break call2. */ > (gdb) bt -past-main > #0 call2 () at /tmp /amd64-shadow-stack.c:21 > #1 0x0000555555555142 in call1 () at /tmp/amd64-shadow-stack.c:27 > #2 0x0000555555555153 in main () at /tmp/amd64-shadow-stack.c:38 > #3 0x00007ffff7c2a1ca in __libc_start_call_main ([...] > #4 0x00007ffff7c2a28b in __libc_start_main_impl ([...]) at ../csu/libc-s= tart.c:360 > #5 0x0000555555555065 in _start () > (gdb) bt -past-main -3 > #3 0x00007ffff7c2a1ca in __libc_start_call_main ([...]) at ../sysdeps/np= tl/libc_start_call_main.h:58 > #4 0x00007ffff7c2a28b in __libc_start_main_impl ([...]) at ../csu/lib= c-start.c:360 > #5 0x0000555555555065 in _start () > (gdb) bt shadow -3 > #2 0x00007ffff7c2a1ca in __libc_start_call_main at ../sysdeps/nptl/libc_= start_call_main.h:74 > #3 0x00007ffff7c2a28b in __libc_start_main_impl at ../csu/libc-start.c:1= 28 > #4 0x0000555555555065 in _start > (gdb) bt shadow > #0 0x0000555555555142 in call1 at /tmp/amd64-shadow-stack.c:28 > #1 0x0000555555555153 in main at /tmp/amd64-shadow-stack.c:39 > #2 0x00007ffff7c2a1ca in __libc_start_call_main at ../sysdeps/nptl/libc_= start_call_main.h:74 > #3 0x00007ffff7c2a28b in __libc_start_main_impl at ../csu/libc-start.c:1= 28 > #4 0x0000555555555065 in _start > ~~~ > > Which is correct from my perspective, but maybe I am missing something.=20 > I think I lost the overview a bit, there are a number of issues in my cod= e here, unfortunately. :/ > Note that for this output I still print the level starting at 0. Will app= ly this change once the other issues are clear. I think this is working for you because of the off-by-one error in the calculation of level in get_trailing_outermost_shadow_stack_frame_info that I mentioned above. I think the off-by-one error here compensates the other one. >> > + { >> > + QUIT; >> > + >> > + print_shadow_stack_frame_info (gdbarch, print_options, *current, >> > + LOCATION); >> > + >> > + trailing =3D current; >> > + current =3D current->unwind_prev_shadow_stack_frame_info (gdbar= ch, >> > + range); >>=20 >> This line fits in 80 columns and doesn't need to be broken. > > Hm, weird, I again count more than 80 columns. Strange indeed. >> > + } >> > + >> > + /* If we've stopped before the end, mention that. */ if (current >> > + && from_tty) >>=20 >> While it's correct to use an std::optional in this way to check whether = it has a >> value, IMHO it's clearer to be more explicit and use the has_value metho= d. >> It's also consistent with the rest of the code in this function. > > I agree. I fixed that. > >> > + gdb_printf (_("(More shadow stack frames follow...)\n")); >> > + >> > + /* If we've run out of shadow stack frames, and the reason appears = to >> > + be an error condition, print it. */ if (!current.has_value () >> > + && trailing.has_value () >>=20 >> If I'm not mistaken, trailing.has_value () is always true at this point. > > I agree, this logic is from backtrace_command_1.=20 > I think adding an assert here should be fine instead, so I suggest the fo= llowing: > > ~~~ > [...] > /* If we've stopped before the end, mention that. */ > if (current.has_value () && from_tty) > gdb_printf (_("(More shadow stack frames follow...)\n")); > > /* Due to the loop above, trailing always has a value at this point. */ > gdb_assert (trailing.has_value ()); > > /* If we've run out of shadow stack frames, and the reason appears to > be an error condition, print it. */ > [...] > ~~~ > > Please let me know if you think otherwise. Looks good to me. --=20 Thiago