From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id R26VHQhxa2o+/jQAWB0awg (envelope-from ) for ; Thu, 30 Jul 2026 11:43:04 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=yahoo.de header.i=@yahoo.de header.a=rsa-sha256 header.s=s2048 header.b=HVCOxzGn; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 64D8A1E099; Thu, 30 Jul 2026 11:43:04 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) 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,FREEMAIL_FROM,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [IPv6:2620:52:6:3111::32]) (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 BA7531E099 for ; Thu, 30 Jul 2026 11:43:01 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 8E12F4BBCDA6 for ; Thu, 30 Jul 2026 15:42:59 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8E12F4BBCDA6 Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=yahoo.de header.i=@yahoo.de header.a=rsa-sha256 header.s=s2048 header.b=HVCOxzGn Received: from sonic311-31.consmr.mail.ir2.yahoo.com (sonic311-31.consmr.mail.ir2.yahoo.com [77.238.176.163]) by sourceware.org (Postfix) with ESMTPS id 5537D4BA2E0C for ; Thu, 30 Jul 2026 15:41:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5537D4BA2E0C Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=yahoo.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=yahoo.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 5537D4BA2E0C Authentication-Results: sourceware.org; arc=none smtp.remote-ip=77.238.176.163 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1785426084; cv=none; b=PfjBU7E425VyHK8v9e7qKDGrd1vEnWWXYGOptZPCFydbogCws/sjLNpoddKLvMxvPdex8Snxjjh6xLmvUr+67x/7SIAQsZ9cnPEAritNInDoBkSLcQHsGLTWVHeWO8EnmUGNFK4Kj5ZmjkYWh0wr8kyt1skwIcXpIdzOL91KnY0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1785426084; c=relaxed/simple; bh=f4ZH6QLVfeEfQD5vc4blx0HCN3RZ/FB+2l/Qq6GSKCE=; h=DKIM-Signature:Date:From:To:Message-ID:Subject:MIME-Version; b=DM54LhYHIUvqeAor2XarMBAp5qCBZiiJR+1KwDboRv9978TAxCfQe2EY+LHbjje5Z+gTGZGREBCrWfSGY/FoV3eW+VgSDgYi3BzqG842ILg3fXF2WMIG87Vx0Hf3g/Z53GKG1kbvsc+PWd5cVQzqeIdUcCX5c/ause8y4+JS5Y0= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=yahoo.de header.i=@yahoo.de header.a=rsa-sha256 header.s=s2048 header.b=HVCOxzGn DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5537D4BA2E0C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.de; s=s2048; t=1785426080; bh=f4ZH6QLVfeEfQD5vc4blx0HCN3RZ/FB+2l/Qq6GSKCE=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject:Reply-To; b=HVCOxzGnBNaFuHZgFXo0to1x0HiRIfruX0r268JfFY9J35fc0kZpX6R7Wo926qTReXUKnTe+1dj8MTWyAmsq5RtmMfgSFQPnZKWbN6vAxWdOn2lyhfFvTuUcA4rZqIeigF9klcaP/3Urs8iswPLx0IUgV6pVk27VGL/x/NwTwZpmeaK6j3Exqlr2rsZVOChWVEQfoyKtGNWaEYr+2ql/ysB7INcpgTd9o3jp16gIJh10BH1ovWGvZrI+xTlhLgAl1lDPb3EO0OMcif818wioKF8eyU4030uAD2EY6PKKGy+DXfVCXYfjpUX0XcaYzAWcnF/X9+PDCKYYJ3AX5m5gJw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1785426080; bh=Wf8CnQIc3R37GM4mIRqSWvLyrtUcUtDpCObEkvgnb85=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=RQjOUvOl9Ssn1xjVxpAPaKLGAvrWtnsNKPZxy3QO6B3QadLmHeVyrUfHZaMmXtCjF1YVNXl8nSxh6AbzZMi5rrvRN60R2YtR0SvGK3gVO43Nlxg7shQ56RvlLVZi1P9poP8QQwHYE22tRkOyobJTN9/G31/9AZjMOPbT6C7YLzdnwBP6goe+YBQXBqg3FYR+SUvfy1vLGeM1ksxpGMIYGJr4Vj0D9Fu1u060yFBXtWSKyKbBLuWOMdMqEqs8Jxwuccevdy8saw9VcIDRmf1NR+okI0ugsAb2IW+VvDcu7tYeHxgYtgh4iwPC9yHlbdAK9RckZeRD3Qh6Kh6ficzFJQ== X-YMail-OSG: jN.C3d0VM1njE1AdWOOR713qJoL_R2SjP2ape2IWbnUkWFUGI4RY4bm8egIMBfI 8G.TvtVVYA8RrDhnEPa3zvZFCiY5DbzNg5X2SGxcb_fVWlRuMdGO6EtDUxLT1o3FrSHv4Mt2tYNI kUdSC7c6aMYpu1SmH.8chshLe70u0uP4zwEID.m9SVOt7Lo_fNtpgNVHS_gbHHY5NGyxEeaWBawS q6Lzd8ZYEKBr4rqMyGR33c3KJlkqw_ysAk5J9GIQ.NoMpvwrjUidyyzhXbvtCjkmjZ8r3beJFP5p 98o1xi80MOG6JhigQpBkSvuVHwUEXKRSMQEf.40O_R3keMGQVODTeNa_0eVlJR8d0b4A2_uPPFTW Us_jq7rP8m13kEyMLZc7t8nraXy1lQfs6e4Vs9dKjSaEbmK0v60AinmScSkJHmKne6ln1LnaChEQ Ar_jso2evkp9nVjDmZrlNXPw8MnDPc7xFsLTuq45TfpXrYBVaBxEbmkyiaFyP6.DqZ7w7STwqqkD wneXF5IO3bjRP0tbm8k9.oJFcq8.i_J2Gx1lLX9E4JaN2eRFIe0U11LSjEdgCl_SJ8CUjUnwyqVi e63rtqlyPKvbX4_nqgizfhR8uJOZiF1FAQ2oWU8ESa1yYoOxq2eciCGZBdlCZGZzDXSa.g7vOje0 iWZsJ6dTnZNhBEhrBM7eYOStSii6opq2ITFJk5QoBBkr...J3.5P30ezpS4r_NDUk373El6_qqjM xKPwBW.Ey0TeLu3dWoPNVRiK1aLBvqchHeCmavTC.iLjGXuFa420AIrUWk.DAFGFLPLnsZkkTVe5 3mkwPf_l6S3yPow5XC1zU7L7YtEt3Hw2yZw5icEI7bI_LgHAZ_xY_dF5M1G3IxR7yN9xBUKQYGbd V1x2nkPjafaL6VY_1g7TmwGelPMI3GJS9_Wtz7kyPWBdA9jhInyn46lONuj1.IvGYTMJ8QrGvXEh SfuCXHBcMRKR3stLznTXracd0kTZOs5X.Qt_I24jvhdGccSRnvMbh0WQwLE.dvsZYW1b9jKOvB_8 tsAMdFjfPp5EB7xR1WKmiWPgvOAB61kZ4wt0lN.wYPBQfD2D132IFQ1ZQvftqTMZ.lMaTbUTZTO9 mWQol45QqE_FZXPCIkYxDGW65CFRkstshI0viwtB.TK..j8EwDxKEdB5OZeNoelK_RSZn5KjKgjb TZ7cVHhYv1DRKQ0Sbv4THiGRU0i5F7iIwL4N12Pd6l2kqxfj2E.SmOtxpnQOB8J.LTj_250UllYW Hp6pHcYqi1_B1PagH748t1TWF1VvFqnNK80l.kNkTd.1zSZdCPrQtwdrL60GXLGwwY3k1cb7Q8Sy wNhJNET112M.YI9a69mQHRw.GNIaKGSR5Pzcw5uhQ9ViyER9Nrq5jzmpkw1TT4MSm5S8cItZr4GN OFqoBGCUXPgUaPL.J1MtMTB1UB8cVsOVQM2IeTQXUvsyppBC_aTUcsBMAdIQTGK6.kYXC.3FThpH rlwd8v9JICGnU0rMt3A.eBQpX1sNxy.i48bgPBUkgl7rnhGEpyEge9bFHaIn7g4J6HP1mdqNJFnB iD182jgN_sVjATkYPPEjhAeNkH311B7uhHd2TdWAOobJ1yQuWon_zlfPL47segwDPTTDE1WygESf W_PDMidn2HxskvN5yb9Asv4hvUU_3y3QWbMoOfc9iCwCZQ4aR4cCweGFBcFZGYa.L.AI9upTef1F 9dM7HKxcNLnBliYqmNnV0bGPsQwMcPNHNFvmKRZeoSqNItZ5QxBXLnTAJYt8jrZI95zzVi7P7LN3 peEhW0RI_wAB.NsE5y8QE64qo78oY5jPMzGTtcIN__nFkSdcsp6Wuo0NaxgayGOPSBN6tVEShMNr 6MnW20xbOvMflYQqIE2Q91mIHLsvZ.C91HZUnBJ1.UALWWtJjlbf4AI1tTAQSnNBYrfNrIO5haB3 RB5GViAmk.OHFETKt1a5mX85KAE3BErRutAw.XHpYx4x.a5n1B2pkDBLyQYdkbCSDH24NXBXzTVw FBc701jRqMGLR6RIAMMIO8VLSynHBOIA1XqJb8aHT8SIrUOnBaitHOg_Br2caUoy_qWyhvluj4jj g4LBC1vOUyz4QKsnvDDM6OyYyT8zkssHxYGBoELdaxzQbPHkVtkEQ2WQ51NtDbRCvqhrX7aSHbkF XwaxQG4WM7kGtJnYuaoiJ724wFO0hn6fB60QZiEGDRwSch1if1ZLjW.AdI_dKVELeHFdhOs1t60O e2f5MqdnMhVzOXfJItSEUw3DYvYhzJrnoD83aQbCLDwKZFCToZpQlyLzgJksEGsNOii8RlmekgnL m X-Sonic-MF: X-Sonic-ID: 21f6373e-4db5-44cf-8aa5-e2639678895e Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.ir2.yahoo.com with HTTP; Thu, 30 Jul 2026 15:41:20 +0000 Date: Thu, 30 Jul 2026 15:41:18 +0000 (UTC) From: Hannes Domani To: "gdb-patches@sourceware.org" , "Joos, Christina" Message-ID: <354146047.5478567.1785426078175@mail.yahoo.com> In-Reply-To: References: <20260712113229.3695246-1-ssbssa@yahoo.de> <20260712113229.3695246-7-ssbssa@yahoo.de> <1783589955.3451825.1784296008828@mail.yahoo.com> <1971012298.3491204.1784299790735@mail.yahoo.com> <1319283533.3531812.1784305616658@mail.yahoo.com> <711725229.188625.1784390808447@mail.yahoo.com> Subject: Re: [PATCH 7/8] Windows gdb: Implement XState (Intel AVX) support MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: WebService/1.1.26180 YMailNorrin 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 Am Donnerstag, 30. Juli 2026 um 10:20:53 MESZ hat Joos, Christina Folgendes geschrieben: > > -----Original Message----- > > From: Hannes Domani > > Sent: Samstag, 18. Juli 2026 18:07 > > To: gdb-patches@sourceware.org; Schimpe, Christina > > > > Subject: Re: [PATCH 7/8] Windows gdb: Implement XState (Intel AVX) supp= ort > > > >=C2=A0 Am Freitag, 17. Juli 2026 um 21:06:16 MESZ hat Schimpe, Christina > > Folgendes geschrieben: > > > > > > -----Original Message----- > > > > From: Hannes Domani > > > > Sent: Freitag, 17. Juli 2026 18:27 > > > > To: gdb-patches@sourceware.org; Schimpe, Christina > > > > > > > > Subject: Re: [PATCH 7/8] Windows gdb: Implement XState (Intel AVX) > > > > support > > > > > > > >=C2=A0 Am Freitag, 17. Juli 2026 um 17:26:14 MESZ hat Schimpe, Chris= tina > > > > Folgendes geschrieben: > > > > > > > > > > -----Original Message----- > > > > > > From: Hannes Domani > > > > > > Sent: Freitag, 17. Juli 2026 16:50 > > > > > > To: gdb-patches@sourceware.org; Schimpe, Christina > > > > > > > > > > > > Subject: Re: [PATCH 7/8] Windows gdb: Implement XState (Intel > > > > > > AVX) support > > > > > > > > > > > >=C2=A0 Am Freitag, 17. Juli 2026 um 16:16:31 MESZ hat Schimpe, > > > > > >Christina Folgendes geschrieben: > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Hannes Domani > > > > > > > > Sent: Freitag, 17. Juli 2026 15:47 > > > > > > > > To: gdb-patches@sourceware.org; Schimpe, Christina > > > > > > > > > > > > > > > > Subject: Re: [PATCH 7/8] Windows gdb: Implement XState > > > > > > > > (Intel > > > > > > > > AVX) support > > > > > > > > > > > > > > > >=C2=A0 Am Freitag, 17. Juli 2026 um 14:54:59 MESZ hat Schimp= e, > > > > > > > >Christina Folgendes geschriebe= n: > > > > > > > > > > > > > > > > > Hi Hannes, > > > > > > > > > > > > > > > > > > Thank you for working on this. > > > > > > > > > It appears that this patch uses the same commit message > > > > > > > > > header as patch #8. Is it intentional that these are sepa= rate > > commits? > > > > > > > > > > > > > > > > This one is the gdb part, and #8 is the gdbserver part, tha= t > > > > > > > > is stated in the title. > > > > > > > > > > > > > > Oups, I wonder how I came to that conclusion.=C2=A0 Sorry for= that. > > > > > > > > > > > > > > > > > > > > > > > > In any case, IMO, commit messages should not have identic= al > > headers. > > > > > > > > > Also, this patch seems big enough for a commit message > > > > > > > > > which is not header only. :) > > > > > > > > > > > > > > This part still stands for the commit message. Since it's not > > > > > > > only avx registers, I believe it makes sense to share more de= tails here. > > > > > > > > > > > > Yes, I will do that. > > > > > > > > > > > > > > > > > > > > > Do any AVX-* specific tests pass on Windows now? If so, i= t > > > > > > > > > would be helpful to mention that in the commit message as= well. > > > > > > > > > > > > > > > > I actually planned to add that info, but forgot. > > > > > > > > > > > > > > > > These tests then pass on Windows: > > > > > > > > gdb.arch/i386-avx.exp > > > > > > > > gdb.arch/i386-avx512.exp > > > > > > > > > > > > > > What's the state for SSE=C2=A0 (gdb.arch/i386-sse.exp) ? > > > > > > > > > > > > i386-sse.exp works since patch #1, it was only a compile issue > > > > > > of the test itself. > > > > > > I will mention this in the patch as well. > > > > > > > > > > Thanks. > > > > > > > > > > > > > > > > > > I also saw you introduced some code for PKRU and the shadow > > > > > > > stack > > > > > > pointer. > > > > > > > We have GDB tests for those registers, too: > > > > > > > - gdb.arch/i386-pkru.exp > > > > > > > - gdb.arch/amd64-shadow-stack*.exp > > > > > > > > > > > > For these I just added the equivalent code as is done on Linux, > > > > > > without really knowing what they are for. > > > > > > > > > > > > i386-pkru.exp tells me: > > > > > > > > > > > > (gdb) print have_pkru() > > > > > > $1 =3D 0 > > > > > > (gdb) PASS: gdb.arch/i386-pkru.exp: probe PKRU support > > > > > > UNSUPPORTED: gdb.arch/i386-pkru.exp: processor does not support > > > > > > protection key feature. > > > > > > > > > > > > Do only certain CPU's have this register? > > > > > > > > > > Most recent CPUs should have it. To be sure you can check if the > > > > > corresponding bit is configured in xcr0. > > > > > > > > I thought that's what have_pkru() does, but I might be wrong about = that. > > > > > > Yes, this should work for windows, too. > > > > > > > > I believe for windows this should be the mask returned by > > > > get_xstate_features_mask. > > > > > > > > You probably mean GetEnabledXStateFeatures, but yes, it also tells > > > > me my CPU doesn't support this. > > > > > > > > > > > > > If your cpu does have it, I think you must look at the test in > > > > > more detail to find out why it's unsupported. It might need some > > > > > adaptions for > > > > windows. > > > > Google tells me only not all recent CPUs have this, is mine one of = them?: > > > > 11th Gen Intel(R) Core(TM) i7-11850H > > > > > > I would have expected this but cannot say for sure.=C2=A0 And I don't= know > > > the state for Memory Protection Keys windows support. > > > > I have tested this now on another PC, one where have_pkru() returns 1, = so this > > CPU really should have PKRU. > > > > But GetEnabledXStateFeatures still does not return the PKRU bit, and I = can find > > no equivalent XSTATE_PKRU define in winnt.h, this makes me believe that > > windows just doesn't support this feature. > > > > So I'm fine with removing that part. > > > > > > > > > > And amd64-shadow-stack.exp: > > > > > > > > > > > > (gdb) print $pl3_ssp > > > > > > $1 =3D (void *) 0x0 > > > > > > (gdb) FAIL: gdb.arch/amd64-shadow-stack.exp: test shadow stack > > > > > > support > > > > > > > > > > > > No idea if that should work, since Windows is supplying data fo= r > > > > > > the $pl3_ssp register. > > > > > > > > > > > > > > > > > > Hannes > > > > > > > > > > Without knowing any of the details in windows I believe adding > > > > > full support for CET shadow stack might need some more changes. A= t > > > > > least for > > > > linux, this was the case: > > > > > https://inbox.sourceware.org/gdb-patches/20250821171029.1555603-1= - > > > > > chri > > > > > stina.schimpe@intel.com/ > > > > > > > > > > I believe it would be better to handle this in a separate patch-(= series). > > > > > This also applies for any other register that you add and whose > > > > > dedicated > > > > test does not pass. > > > > > > > > > > Does that make sense to you? > > > > > > > > I was wondering if it isn't the compiler or linker on windows (or > > > > maybe windows itself?) that doesn't support this -fcf-protection=3D= return stuff. > > > > > > I don't know the state for windows but would be curious about it. :-) > > > At least for Kernel Mode, I could find some documentation for it. > > > > I did some more tests here as well. > > > > It turns out binutils/gcc really don't support this on windows yet. > > To enable this in the executable, at least a special marker bit has to = be set in the > > Extended DLL Characteristics [1]. > > With msvc you can do that with the /CETCOMPAT linker argument [2]. > > So I compiled amd64-shadow-stack.c with msvc and /CETCOMPAT, and tried = it > > out with my gdb build. > > Before I always got $pl3_ssp=3D0, and with this new exe I always get $p= l3_ssp=3D1. > > > > So I had this wrong, because LocateXStateFeature returns for XSTATE_CET= _U this > > struct: > >=C2=A0 =C2=A0 =C2=A0typedef struct _XSAVE_CET_U_FORMAT { > >=C2=A0 =C2=A0 =C2=A0 =C2=A0DWORD64 Ia32CetUMsr; > >=C2=A0 =C2=A0 =C2=A0 =C2=A0DWORD64 Ia32Pl3SspMsr; > >=C2=A0 =C2=A0 =C2=A0} XSAVE_CET_U_FORMAT, *PXSAVE_CET_U_FORMAT; > > > > So $pl3_ssp showed Ia32CetUMsr, when it should have shown Ia32Pl3SspMsr > > instead. > > > > With that fixed, I tried again debugging the /CETCOMPAT executable: >=C2=A0 > Ah ok, good to know. >=C2=A0 > > (gdb) r > > Starting program: C:\qiewer\git\amd64-shadow-stack.exe > > > > Breakpoint 1, 0x00007ff725812e41 in ?? () > > 1: $pl3_ssp =3D (void *) 0x4feff0 > > (gdb) x/1i $pc > > =3D> 0x7ff725812e41:=C2=A0 =C2=A0 =C2=A0 jmp=C2=A0 =C2=A0 0x7ff72581768= 0 > > (gdb) x/4a $pl3_ssp > > 0x4feff0:=C2=A0 =C2=A0 =C2=A0 =C2=A00x7ffd62fee957 > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x7ffd6364= 7c1c > > > > 0x4ff000:=C2=A0 =C2=A0 =C2=A0 =C2=A0Cannot access memory at address 0x4= ff000 > > (gdb) si > > ... > > (gdb) si > > 0x00007ff725817684 in ?? () > > 1: $pl3_ssp =3D (void *) 0x4feff0 > > (gdb) x/1i $pc > > =3D> 0x7ff725817684:=C2=A0 =C2=A0 =C2=A0 call=C2=A0 =C2=A00x7ff725812f1= d > > (gdb) si > > 0x00007ff725812f1d in ?? () > > 1: $pl3_ssp =3D (void *) 0x4fefe8 > > (gdb) x/4a $pl3_ssp > > 0x4fefe8:=C2=A0 =C2=A0 =C2=A0 =C2=A00x7ff725817689=C2=A0 0x7ffd62fee957 > > > > 0x4feff8:=C2=A0 =C2=A0 =C2=A0 =C2=A00x7ffd63647c1c =C2=A0 =C2=A0 Cannot access > > memory at address 0x4ff000 > > (gdb) x/1i $pc > > =3D> 0x7ff725812f1d:=C2=A0 =C2=A0 =C2=A0 jmp=C2=A0 =C2=A0 0x7ff725817c3= 0 > > (gdb) si > > ... > > (gdb) si > > 0x00007ff725817cde in ?? () > > 1: $pl3_ssp =3D (void *) 0x4fefe8 > > (gdb) x/1i $pc > > =3D> 0x7ff725817cde:=C2=A0 =C2=A0 =C2=A0 ret > > (gdb) si > > 0x00007ff725817689 in ?? () > > 1: $pl3_ssp =3D (void *) 0x4feff0 > > (gdb) x/1i $pc > > =3D> 0x7ff725817689:=C2=A0 =C2=A0 =C2=A0 add=C2=A0 =C2=A0 $0x28,%rsp > > (gdb) x/4a $pl3_ssp > > 0x4feff0:=C2=A0 =C2=A0 =C2=A0 =C2=A00x7ffd62fee957 > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x7ffd6364= 7c1c > > > > 0x4ff000:=C2=A0 =C2=A0 =C2=A0 =C2=A0Cannot access memory at address 0x4= ff000 > > (gdb) > > > > call and ret modify the shadow stack which is pointed to by $pl3_ssp, i= s that how > > it's supposed to work? >=C2=A0 > Yeah kind of, you can read it up here: > https://inbox.sourceware.org/gdb-patches/20250821171029.1555603-9-christi= na.schimpe@intel.com/ > https://inbox.sourceware.org/gdb-patches/20250821171029.1555603-10-christ= ina.schimpe@intel.com/ >=C2=A0 > > I'm unsure, because amd64-shadow-stack-cmds.exp makes it look like $pl3= _ssp > > should change when moving up or down the frames. >=C2=A0 > This is also described in the commit message/gdb.texinfo docs. > The corresponding test is amd64-shadow-stack-cmds.exp. That's more or less working like I thought. But why do we unwind $pl3_ssp when moving up the frames, couldn't it just stay the same in all frames? > > Is $pl3_ssp maybe supposed to provide Ia32Pl3SspMsr[$frame] instead? > > How does that work on linux? > > > > In any case, I tried modifying $pl3_ssp like it is done in amd64-shadow= - > > stack.exp. > > > > (gdb) p $pl3_ssp > > $10 =3D (void *) 0x4fefe8 > > (gdb) p $pl3_ssp=3D0x12345678 > > $11 =3D (void *) 0x12345678 > > (gdb) ni > > error return C:/gdb/src/gdb.git/gdb/x86-windows-nat.c:242 was 1660: The= thread > > context could not be updated because this has been restricted for the p= rocess. > > 0x00007ffd63720574 in ntdll!ZwMapViewOfSection () from > > C:\WINDOWS\SYSTEM32\ntdll.dll > > > > So windows doesn't allow modifying the shadow stack pointer. > > (gdb) p $pl3_ssp > > $14 =3D (void *) 0x4fefe8 > > (gdb) p ((void**)$pl3_ssp)[0] > > $15 =3D (void *) 0x7ff725817689 > > (gdb) p ((void**)$pl3_ssp)[0]=3D0x12345678 Cannot access memory at addr= ess > > 0x4fefe8 > > > > And looks like modifying the shadow stack entries is also prohibited. >=C2=A0 > If writing to shadow stack memory and pushing entries on the shadow stack > does not work in windows,=C2=A0 displaced stepping, the return command, i= nferior > function calls and frame updates cannot be enabled for shadow stack enabl= ed > programs. >=C2=A0 > In linux we have a ptrace call to read and write the shadow stack pointer= : > https://github.com/torvalds/linux/blob/11028ab62899e4191e074ee364c712b778= 23a9c4/tools/testing/selftests/x86/test_shadow_stack.c#L994 Yeah, it really looks like modifying the shadow stack isn't possible on win= dows. I just tried doing a function call in windbg: 0:000> .call call1() Thread is set up for call, 'g' will execute. WARNING: This can have serious side-effects, including deadlocks and corruption of the debuggee. 0:000> g (6854.108c): Security check failure or stack buffer overrun - code c0000409= (!!! second chance !!!) Subcode: 0x39 FAST_FAIL_CONTROL_INVALID_RETURN_ADDRESS Shadow stack violati= on amd64_shadow_stack_cet!call1+0xd: And only reading the ssp register is possible there: 0:000> r ssp ssp=3D000000b5470fefe0 0:000> r ssp=3D000000b5470fefe1 Amd64MachineInfo::SetVal: unknown register 9c requested =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 ^ Bad register error in 'r ssp=3D000000b5470fefe1' Hannes