All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: "Roger Pau Monné" <roger.pau@citrix.com>, "Wei Liu" <wl@xen.org>,
	"Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>,
	Xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH] x86/cet: Fix shskt manipulation error with BUGFRAME_{warn,run_fn}
Date: Fri, 13 Aug 2021 16:00:41 +0200	[thread overview]
Message-ID: <94239a81-1d8a-e6ec-f572-9c8d5f3ec50f@suse.com> (raw)
In-Reply-To: <20210812170350.23543-1-andrew.cooper3@citrix.com>

On 12.08.2021 19:03, Andrew Cooper wrote:
> This was a clear oversight in the original CET work.  The BUGFRAME_run_fn and
> BUGFRAME_warn paths update regs->rip without an equivlenet adjustment to the
> shadow stack, causes IRET to suffer #CP due to the mismatch.
> 
> One subtle, and therefore fragile, aspect of extable_shstk_fixup() was that it
> required regs->rip to have its old value as a cross-check that the correct
> word in the shadow stack was being adjusted.
> 
> Rework extable_shstk_fixup() into fixup_exception_return() which takes
> ownership of the update to both the regular and shadow stacks, ensuring that
> the regs->rip update is ordered suitably.
> 
> Use the new fixup_exception_return() for BUGFRAME_run_fn and BUGFRAME_warn to
> ensure that the shadow stack is updated too.
> 
> Fixes: 209fb9919b50 ("x86/extable: Adjust extable handling to be shadow stack compatible")
> Reported-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>

> I'm not a massive fan of the large ifdef area.  The logic could be rearranged
> to use IS_ENABLED(CONFIG_XEN_SHSTK) by indenting most of the function, but I
> can't see any way to drop the goto's, and this is certainly the least-invasive
> diff.

It's not really neat, but we've got worse code elsewhere.

I wonder whether gdb_arch_resume() and gdb_arch_write_reg() also
need some sort of similar adjustment.

Jan



  parent reply	other threads:[~2021-08-13 14:01 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-12 17:03 [PATCH] x86/cet: Fix shskt manipulation error with BUGFRAME_{warn,run_fn} Andrew Cooper
2021-08-12 18:16 ` Marek Marczykowski-Górecki
2021-08-13 14:00 ` Jan Beulich [this message]
2021-08-16 10:31   ` Andrew Cooper
2021-08-17  9:10 ` Jan Beulich
2021-08-17 10:31   ` 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=94239a81-1d8a-e6ec-f572-9c8d5f3ec50f@suse.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=marmarek@invisiblethingslab.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.