All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Andryuk <jandryuk@gmail.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: "Stefan Bader" <stefan.bader@canonical.com>,
	Xen-devel <xen-devel@lists.xenproject.org>,
	"Wei Liu" <wl@xen.org>, "Jan Beulich" <JBeulich@suse.com>,
	"Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [PATCH] x86/build: Unilaterally disable -fcf-protection
Date: Wed, 13 May 2020 08:15:19 -0400	[thread overview]
Message-ID: <CAKf6xpv-5gy-eiMN49w99ZpeGzNH5R2x3YmwOR+ZZsnCzb_5Gg@mail.gmail.com> (raw)
In-Reply-To: <6b7871d8-903a-20df-4e19-9a6200094aa5@citrix.com>

On Wed, May 13, 2020 at 7:01 AM Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>
> On 13/05/2020 03:35, Jason Andryuk wrote:
> > [CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open attachments unless you have verified the sender and know the content is safe.
> >
> > On Tue, May 12, 2020 at 3:11 PM Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> >> +# Xen doesn't support CET-IBT yet.  At a minimum, logic is required to
> >> +# enable it for supervisor use, but the Livepatch functionality needs
> >> +# to learn not to overwrite ENDBR64 instructions.
> > Is the problem that existing functions start with ENDBR64, but the
> > livepatch overwrites with a "real" instruction?
>
> We livepatch by creating a new complete copy of the function, and
> putting `jmp new` at the head of the old one.
>
> This means we don't need to patch every callsite and track every
> function pointer to the old function, and we can fully revert by
> replacing the 5 bytes which became `jmp new`.
>
> With CET-IBT in the mix, livepatch will have to learn to spot an ENDBR64
> instruction and leave it intact, patching instead the next 5 bytes, so
> an old function pointer still lands on the ENDBR64 instruction.

Ah, okay.  Thanks for the explanation.

-Jason


  reply	other threads:[~2020-05-13 12:15 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-12 19:11 [PATCH] x86/build: Unilaterally disable -fcf-protection Andrew Cooper
2020-05-13  2:35 ` Jason Andryuk
2020-05-13 11:01   ` Andrew Cooper
2020-05-13 12:15     ` Jason Andryuk [this message]
2020-05-13  9:15 ` Jan Beulich
2020-05-13 13:55 [PATCH] build: Fix build with Ubuntu Andrew Cooper
2020-05-13 13:55 ` [PATCH] x86/build: Unilaterally disable -fcf-protection Andrew Cooper
2020-05-13 14:13   ` Jan Beulich
2020-05-13 14:40     ` Andrew Cooper
2020-05-13 14:54   ` Jason Andryuk

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=CAKf6xpv-5gy-eiMN49w99ZpeGzNH5R2x3YmwOR+ZZsnCzb_5Gg@mail.gmail.com \
    --to=jandryuk@gmail.com \
    --cc=JBeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=roger.pau@citrix.com \
    --cc=stefan.bader@canonical.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.