public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: "H.J. Lu" <hjl.tools@gmail.com>
To: "szabolcs.nagy@arm.com" <szabolcs.nagy@arm.com>
Cc: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>,
	 "libc-alpha@sourceware.org" <libc-alpha@sourceware.org>
Subject: Re: [PATCH 11/17] x86/cet: Sync with Linux kernel 6.6 shadow stack interface
Date: Mon, 18 Dec 2023 11:06:38 -0800	[thread overview]
Message-ID: <CAMe9rOp0uQq0MWk1JAaZodD1K_w9Caap+=ycoLLQvgc6FFmP2g@mail.gmail.com> (raw)
In-Reply-To: <ZYAkudp3BwnpvCtn@arm.com>

[-- Attachment #1: Type: text/plain, Size: 2207 bytes --]

On Mon, Dec 18, 2023 at 2:54 AM szabolcs.nagy@arm.com
<szabolcs.nagy@arm.com> wrote:
>
> The 12/15/2023 09:08, H.J. Lu wrote:
> > On Fri, Dec 15, 2023 at 1:23 AM szabolcs.nagy@arm.com
> > <szabolcs.nagy@arm.com> wrote:
> > >
> > > The 12/14/2023 09:40, H.J. Lu wrote:
> > > > On Thu, Dec 14, 2023 at 9:13 AM szabolcs.nagy@arm.com
> > > > > so the rule can be that if a user wants a stack to be resumable
> > > > > then a restore token must be placed on that stack when switching
> > > >
> > > > That is fine.
> > > >
> > > > > away from it, if the token is not there then longjmp is ub and
> > > > > may crash. (so no need to check for 0, such longjmp is a user error)
> > > >
> > > > We need to check for 0.  Otherwise, all current setjmp tests segfault
> > > > since there is no restore token on the target shadow stack.
> > >
> > > i don't understand this claim.
> > >
> > > any longjmp target ssp is either
> > > - on the same stack: you can check targetssp == ssp
> > > - or different stack: you can check *targetssp == restore token
> > > as you scan the target ssp.
> >
> > longjmp doesn't know if the target SSP is on the same shadow stack.
> >
>
> it does if it scans.
>
> for (;; targetssp--) {
>   if (targetssp == ssp) do_samestack();
>   if (*targetssp == restoretoken) do_differentstack();
> }
>
> the only problem i see is if the target shadow stack is
> different from the current one and does not end in a restore
> token. but i think that is a user error.

Yes, it works.  But it is hard to tell its performance overhead.

> if we plan to introduce altshadowstack then this does not
> work in case of shadow stack overflow because the overflowed
> shadow stack cannot be jumped to even though in practice we
> want that to work.
>

I'd like to support shadow stack in glibc 2.39.  Since my patch
doesn't enable shadow stack by default, it doesn't have any
functionality impact on users.  It allows us to evaluate shadow
stack support in all packages.  We may need to use WRUSS
to enable shadow stack for some packages.  But users and
developers can't see how shadow stack works if shadow stack
can't be turned on.

-- 
H.J.

[-- Attachment #2: 0001-x86-64-cet-Check-the-restore-token-in-longjmp.patch --]
[-- Type: text/x-patch, Size: 2301 bytes --]

From 3dba6d876db6a47b66a680bb4aa85b1db63aa3f8 Mon Sep 17 00:00:00 2001
From: "H.J. Lu" <hjl.tools@gmail.com>
Date: Wed, 13 Dec 2023 17:50:47 -0800
Subject: [PATCH] x86-64/cet: Check the restore token in longjmp

setcontext and swapcontext put a restore token on the old shadow stack
so that they switch to a different shadow stack when switching user
contexts.  When longjmp from a user context, the target shadow stack
can be different from the current shadow stack and INCSSP can't be
used to restore the shadow stack pointer to the target shadow stack.
Update longjmp to search for a restore token.  If found, use the token
to restore the shadow stack pointer before using INCSSP to pop the
shadow stack.  Stop the token search and use INCSSP if the shadow stack
entry value is the same as the current shadow stack pointer.

It is a user error if there is a shadow stack switch without leaving a
restore token on the old shadow stack.
---
 sysdeps/x86_64/__longjmp.S | 28 +++++++++++++++++++++++++++-
 1 file changed, 27 insertions(+), 1 deletion(-)

diff --git a/sysdeps/x86_64/__longjmp.S b/sysdeps/x86_64/__longjmp.S
index 9ac075e0a8..b106affdcd 100644
--- a/sysdeps/x86_64/__longjmp.S
+++ b/sysdeps/x86_64/__longjmp.S
@@ -63,9 +63,35 @@ ENTRY(__longjmp)
 	/* Check and adjust the Shadow-Stack-Pointer.  */
 	/* Get the current ssp.  */
 	rdsspq %rax
+	/* Save the current ssp.  */
+	movq %rax, %r10
 	/* And compare it with the saved ssp value.  */
-	subq SHADOW_STACK_POINTER_OFFSET(%rdi), %rax
+	movq SHADOW_STACK_POINTER_OFFSET(%rdi), %rcx
+	subq %rcx, %rax
 	je L(skip_ssp)
+
+L(find_restore_token_loop):
+	/* Look for a restore token.  */
+	movq -8(%rcx), %rbx
+	andq $-8, %rbx
+	cmpq %rcx, %rbx
+	/* Find the restore token.  */
+	je L(restore_shadow_stack)
+
+	/* Try the next slot.  */
+	subq $8, %rcx
+	/* Stop if the current ssp is found.  */
+	cmpq %rcx, %r10
+	je L(no_shadow_stack_token)
+	jmp L(find_restore_token_loop)
+
+L(restore_shadow_stack):
+	/* Restore the target shadow stack.  */
+	rstorssp -8(%rcx)
+	rdsspq %rax
+	subq SHADOW_STACK_POINTER_OFFSET(%rdi), %rax
+
+L(no_shadow_stack_token):
 	/* Count the number of frames to adjust and adjust it
 	   with incssp instruction.  The instruction can adjust
 	   the ssp by [0..255] value only thus use a loop if
-- 
2.43.0


  reply	other threads:[~2023-12-18 19:07 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-06 17:19 [PATCH 00/17] x86/cet: Update CET kernel interface H.J. Lu
2023-12-06 17:19 ` [PATCH 01/17] x86/cet: Check user_shstk in /proc/cpuinfo H.J. Lu
2023-12-06 17:19 ` [PATCH 02/17] x86/cet: Update tst-cet-vfork-1 H.J. Lu
2023-12-06 17:19 ` [PATCH 03/17] x86/cet: Don't assume that SHSTK implies IBT H.J. Lu
2023-12-06 17:19 ` [PATCH 04/17] x86/cet: Check legacy shadow stack applications H.J. Lu
2023-12-06 17:19 ` [PATCH 05/17] x86/cet: Check CPU_FEATURE_ACTIVE when CET is disabled H.J. Lu
2023-12-06 23:53   ` Noah Goldstein
2023-12-07 21:07     ` H.J. Lu
2023-12-06 17:19 ` [PATCH 06/17] x86/cet: Add tests for GLIBC_TUNABLES=glibc.cpu.hwcaps=-SHSTK H.J. Lu
2023-12-06 17:20 ` [PATCH 07/17] x86/cet: Check legacy shadow stack code in .init_array section H.J. Lu
2023-12-06 17:20 ` [PATCH 08/17] x86/cet: Check CPU_FEATURE_ACTIVE in permissive mode H.J. Lu
2023-12-06 17:20 ` [PATCH 09/17] x86: Check PT_GNU_PROPERTY early H.J. Lu
2023-12-06 23:57   ` Noah Goldstein
2023-12-07 21:06     ` H.J. Lu
2023-12-06 17:20 ` [PATCH 10/17] x86: Modularize sysdeps/x86/dl-cet.c H.J. Lu
2023-12-06 17:20 ` [PATCH 11/17] x86/cet: Sync with Linux kernel 6.6 shadow stack interface H.J. Lu
2023-12-11 11:34   ` Szabolcs Nagy
2023-12-11 16:44     ` H.J. Lu
2023-12-12 18:02       ` Szabolcs Nagy
2023-12-12 18:39         ` H.J. Lu
2023-12-13 10:48           ` Szabolcs Nagy
2023-12-13 22:45             ` H.J. Lu
2023-12-13 23:54               ` Edgecombe, Rick P
2023-12-14  0:20                 ` H.J. Lu
2023-12-14  2:21                   ` H.J. Lu
2023-12-14 17:13                     ` szabolcs.nagy
2023-12-14 17:40                       ` H.J. Lu
2023-12-14 23:00                         ` Edgecombe, Rick P
2023-12-14 23:47                           ` H.J. Lu
2023-12-15  1:00                             ` Edgecombe, Rick P
2023-12-15  9:23                         ` szabolcs.nagy
2023-12-15 17:08                           ` H.J. Lu
2023-12-18 10:53                             ` szabolcs.nagy
2023-12-18 19:06                               ` H.J. Lu [this message]
2023-12-19 17:15                                 ` szabolcs.nagy
2023-12-19 18:12                                   ` H.J. Lu
2023-12-06 17:20 ` [PATCH 12/17] elf: Always provide _dl_get_dl_main_map in libc.a H.J. Lu
2023-12-06 17:20 ` [PATCH 13/17] x86/cet: Enable shadow stack during startup H.J. Lu
2023-12-06 17:20 ` [PATCH 14/17] x86/cet: Check feature_1 in TCB for active IBT and SHSTK H.J. Lu
2023-12-06 17:20 ` [PATCH 15/17] x86/cet: Don't disable CET if not single threaded H.J. Lu
2023-12-06 17:20 ` [PATCH 16/17] x86/cet: Don't set CET active by default H.J. Lu
2023-12-06 17:20 ` [PATCH 17/17] x86/cet: Run some CET tests with shadow stack H.J. Lu

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='CAMe9rOp0uQq0MWk1JAaZodD1K_w9Caap+=ycoLLQvgc6FFmP2g@mail.gmail.com' \
    --to=hjl.tools@gmail.com \
    --cc=libc-alpha@sourceware.org \
    --cc=rick.p.edgecombe@intel.com \
    --cc=szabolcs.nagy@arm.com \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).