All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Xen-devel <xen-devel@lists.xenproject.org>,
	"Wei Liu" <wl@xen.org>, "Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [PATCH v2 12/14] x86/entry: Adjust guest paths to be shadow stack compatible
Date: Fri, 29 May 2020 14:40:54 +0200	[thread overview]
Message-ID: <5be19f55-979a-3cef-18bf-f9673cef1da3@suse.com> (raw)
In-Reply-To: <20200527191847.17207-13-andrew.cooper3@citrix.com>

On 27.05.2020 21:18, Andrew Cooper wrote:
> The SYSCALL/SYSENTER/SYSRET paths need to use {SET,CLR}SSBSY.  The IRET to
> guest paths must not.  In the SYSRET path, re-position the mov which loads rip
> into %rcx so we can use %rcx for CLRSSBSY, rather than spilling another
> register to the stack.
> 
> While we can in principle detect shadow stack corruption and a failure to
> clear the supervisor token busy bit in the SYSRET path (by inspecting the
> carry flag following CLRSSBSY), we cannot detect similar problems for the IRET
> path (IRET is specified not to fault in this case).
> 
> We will double fault at some point later, when next trying to enter Xen, due
> to an already-set supervisor shadow stack busy bit.  As SYSRET is a uncommon
> path anyway, avoid the added complexity for no appreciable gain.

I'm okay with the avoidance of complexity, but why is the SYSRET path
uncommon? Almost all hypercall returns ought to take that path?

> --- a/xen/arch/x86/x86_64/entry.S
> +++ b/xen/arch/x86/x86_64/entry.S
> @@ -191,9 +191,16 @@ restore_all_guest:
>          sarq  $47,%rcx
>          incl  %ecx
>          cmpl  $1,%ecx
> -        movq  8(%rsp),%rcx            # RIP
>          ja    iret_exit_to_guest

This removal from the shared part of the exit path needs to be
reflected on both of the sides of the JA, i.e. ...

>  
> +        /* Clear the supervisor shadow stack token busy bit. */
> +.macro rag_clrssbsy
> +        rdsspq %rcx
> +        clrssbsy (%rcx)
> +.endm
> +        ALTERNATIVE "", rag_clrssbsy, X86_FEATURE_XEN_SHSTK
> +
> +        movq  8(%rsp), %rcx           # RIP

... not just here, but also like this (with the JA above changed
to target the new label):

         ALIGN
 /* No special register assumptions. */
+.Liret_exit_to_guest:
+        movq  8(%rsp),%rcx            # RIP
 iret_exit_to_guest:
         andl  $~(X86_EFLAGS_IOPL|X86_EFLAGS_NT|X86_EFLAGS_VM),24(%rsp)
         orl   $X86_EFLAGS_IF,24(%rsp)

Granted it's mostly cosmetic, as the IRETQ ought to fault, but
it's still a use of IRET in place of SYSRET, and hence we better
get guest register state right. With this or a functionally
identical adjustment (or a clarification on what makes you
convinced this adjustment isn't needed)
Reviewed-by: Jan Beulich <jbeulich@suse.com>

Jan


  reply	other threads:[~2020-05-29 12:41 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-27 19:18 [PATCH v2 00/14] x86: Support for CET Supervisor Shadow Stacks Andrew Cooper
2020-05-27 19:18 ` [PATCH v2 01/14] x86/traps: Clean up printing in {do_reserved, fatal}_trap() Andrew Cooper
2020-05-28  9:45   ` [PATCH v2 01/14] x86/traps: Clean up printing in {do_reserved,fatal}_trap() Jan Beulich
2020-05-27 19:18 ` [PATCH v2 02/14] x86/traps: Factor out extable_fixup() and make printing consistent Andrew Cooper
2020-05-28  9:50   ` Jan Beulich
2020-05-28 17:26     ` Andrew Cooper
2020-05-27 19:18 ` [PATCH v2 03/14] x86/shstk: Introduce Supervisor Shadow Stack support Andrew Cooper
2020-05-28 10:25   ` Jan Beulich
2020-05-28 18:10     ` Andrew Cooper
2020-05-29 11:59       ` Jan Beulich
2020-05-29 15:51         ` Anthony PERARD
2020-05-29 18:39           ` Andrew Cooper
2020-06-02 12:09             ` Jan Beulich
2020-05-29 18:36         ` Andrew Cooper
2020-06-02 12:06           ` Jan Beulich
2020-06-02 12:26             ` Anthony PERARD
2020-06-02 12:41               ` Jan Beulich
2020-06-02 13:50                 ` Anthony PERARD
2020-06-02 14:13                   ` Jan Beulich
2020-05-27 19:18 ` [PATCH v2 04/14] x86/traps: Implement #CP handler and extend #PF for shadow stacks Andrew Cooper
2020-05-28 12:03   ` Jan Beulich
2020-05-28 13:22     ` Andrew Cooper
2020-05-28 13:31       ` Jan Beulich
2020-05-29 18:50         ` Andrew Cooper
2020-05-27 19:18 ` [PATCH v2 05/14] x86/shstk: Re-layout the stack block " Andrew Cooper
2020-05-28 12:33   ` Jan Beulich
2020-05-29 19:21     ` Andrew Cooper
2020-05-27 19:18 ` [PATCH v2 06/14] x86/shstk: Create " Andrew Cooper
2020-05-28 12:50   ` Jan Beulich
2020-05-29 19:35     ` Andrew Cooper
2020-05-29 21:45       ` Andrew Cooper
2020-06-02 12:32         ` Jan Beulich
2020-06-02 12:35       ` Jan Beulich
2020-05-27 19:18 ` [PATCH v2 07/14] x86/cpu: Adjust enable_nmis() to be shadow stack compatible Andrew Cooper
2020-05-27 19:18 ` [PATCH v2 08/14] x86/cpu: Adjust reset_stack_and_jump() " Andrew Cooper
2020-05-28 14:41   ` Jan Beulich
2020-05-27 19:18 ` [PATCH v2 09/14] x86/spec-ctrl: Adjust DO_OVERWRITE_RSB " Andrew Cooper
2020-05-27 19:18 ` [PATCH v2 10/14] x86/extable: Adjust extable handling " Andrew Cooper
2020-05-28 16:15   ` Jan Beulich
2020-05-29 19:43     ` Andrew Cooper
2020-05-29 21:17       ` Andrew Cooper
2020-06-02 13:11         ` Jan Beulich
2020-06-02 12:57       ` Jan Beulich
2020-05-27 19:18 ` [PATCH v2 11/14] x86/alt: Adjust _alternative_instructions() to not create shadow stacks Andrew Cooper
2020-05-29 12:23   ` Jan Beulich
2020-05-29 19:46     ` Andrew Cooper
2020-05-27 19:18 ` [PATCH v2 12/14] x86/entry: Adjust guest paths to be shadow stack compatible Andrew Cooper
2020-05-29 12:40   ` Jan Beulich [this message]
2020-05-29 19:58     ` Andrew Cooper
2020-05-27 19:18 ` [PATCH v2 13/14] x86/S3: Save and restore Shadow Stack configuration Andrew Cooper
2020-05-29 12:52   ` Jan Beulich
2020-05-29 20:00     ` Andrew Cooper
2020-05-27 19:18 ` [PATCH v2 14/14] x86/shstk: Activate Supervisor Shadow Stacks Andrew Cooper
2020-05-29 13:09   ` Jan Beulich
2020-05-29 20:28     ` Andrew Cooper
2020-05-29 22:28 ` [PATCH v2 00/14] x86: Support for CET " Andrew Cooper

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=5be19f55-979a-3cef-18bf-f9673cef1da3@suse.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=roger.pau@citrix.com \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.