mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: David Woodhouse <dwmw2@infradead.org>,
	Borislav Petkov <bp@alien8.de>,
	KarimAllah Ahmed <karahmed@amazon.com>
Cc: arjan@linux.intel.com, tglx@linutronix.de, karahmed@amazon.de,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	tim.c.chen@linux.intel.com, peterz@infradead.org,
	pbonzini@redhat.com, ak@linux.intel.com,
	torvalds@linux-foundation.org, gregkh@linux-foundation.org
Subject: Re: [PATCH v2 5/8] x86/speculation: Add basic support for IBPB
Date: Sun, 21 Jan 2018 20:19:43 +0000	[thread overview]
Message-ID: <648c29c2-eeda-f34b-e7ea-1be59b60a6e5@citrix.com> (raw)
In-Reply-To: <1516565047.9814.59.camel@infradead.org>

On 21/01/2018 20:04, David Woodhouse wrote:
> On Sun, 2018-01-21 at 19:37 +0000, Andrew Cooper wrote:
>> It doesn't matter if an attacker can use SP1 to try and skip the IBPB.
>>
>> Exits to userspace/guest are serialising (with some retroactive updates
>> to the architecture spec coming), so an attacker can't cause victim code
>> to be executed before speculation has caught up and noticed that the
>> IBPB did need to happen.
> For the specific case of IBPB, knowing what we do about non-
> architectural behaviour, that's probably true.
>
> In the early patch sets in both Xen and Linux, we did have a
> conditional branch on {sys,hyper}call entry that blithely let the CPU
> speculate all the way to the {sys,hyper}call table jump. No exit to
> userspace/guest there.

Right, but that is a different situation.  That is an attacker trying to
attack the kernel/hypervisor directly using SP2, which is mitigated with
retpoline/lfence+jmp/IBRS (as appropriate).

This IBPB case is an attacker trying to attack a new piece of userspace
using SP2, and furthermore, trying to use SP1 to skip the IBPB.

It is an inherent property of all these issues that an attacker can't
cause the misdirected basic blocks to be retired, which means they can't
change the actual behaviour of execution in supervisor context.

As the exit to user/guest context is serialising, the only thing the
attacker can usefully do is tickle a speculatively-leaky block.

> Which is why I've been saying I want call sites to have an *explicit*
> comment saying why they're safe to use conditional branches without
> taking extra steps to be safe, like the 'else lfence'. And why I'd
> really like the underlying primitives to *support* being fixed at
> runtime.

I'm afraid that, by this logic, every conditional branch needs a
comment, and that is impractical.  I don't see what is special about
this conditional branch vs every other conditional branch in the
codebase, and calling it out in isolation feels wrong.

~Andrew

  reply	other threads:[~2018-01-21 20:19 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-21  9:49 [PATCH v2 0/8] Speculation Control feature support, IBPB David Woodhouse
2018-01-21  9:49 ` [PATCH v2 1/8] x86/cpufeatures: Add Intel feature bits for Speculation Control David Woodhouse
2018-01-21 10:17   ` Ingo Molnar
2018-01-21  9:49 ` [PATCH v2 2/8] x86/cpufeatures: Add AMD feature bits for Prediction Command David Woodhouse
2018-01-21 17:50   ` Tom Lendacky
2018-01-21 18:01     ` Andrew Cooper
2018-01-22 14:31       ` Tom Lendacky
2018-01-22 14:33         ` Andrew Cooper
2018-01-21  9:49 ` [PATCH v2 3/8] x86/msr: Add definitions for new speculation control MSRs David Woodhouse
2018-01-21 13:06   ` Jiri Slaby
2018-01-21 13:27     ` David Woodhouse
2018-01-21  9:49 ` [PATCH v2 4/8] x86/pti: Do not enable PTI on fixed Intel processors David Woodhouse
2018-01-21 13:38   ` Borislav Petkov
2018-01-21  9:49 ` [PATCH v2 5/8] x86/speculation: Add basic support for IBPB David Woodhouse
2018-01-21 10:26   ` Ingo Molnar
2018-01-21 18:06   ` Borislav Petkov
2018-01-21 18:29     ` KarimAllah Ahmed
2018-01-21 19:01       ` Borislav Petkov
2018-01-21 19:31         ` David Woodhouse
2018-01-21 19:37           ` Andrew Cooper
2018-01-21 20:04             ` David Woodhouse
2018-01-21 20:19               ` Andrew Cooper [this message]
2018-01-21 21:25                 ` David Woodhouse
2018-01-21 19:53           ` Borislav Petkov
2018-01-21 18:54     ` David Woodhouse
2018-01-21 19:04       ` Borislav Petkov
2018-01-21 19:31         ` David Woodhouse
2018-01-21 19:54           ` Borislav Petkov
2018-01-21 20:07             ` David Woodhouse
2018-01-21 20:17               ` Borislav Petkov
2018-01-21  9:49 ` [PATCH v2 6/8] x86/kvm: Add IBPB support David Woodhouse
2018-01-21 18:06   ` Tom Lendacky
2018-01-21  9:49 ` [PATCH v2 7/8] x86/speculation: Use Indirect Branch Prediction Barrier in context switch David Woodhouse
2018-01-21  9:49 ` [PATCH v2 8/8] x86/mm: Only flush indirect branches when switching into non dumpable process David Woodhouse
2018-01-21 10:33   ` Ingo Molnar

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=648c29c2-eeda-f34b-e7ea-1be59b60a6e5@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=ak@linux.intel.com \
    --cc=arjan@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=dwmw2@infradead.org \
    --cc=gregkh@linux-foundation.org \
    --cc=karahmed@amazon.com \
    --cc=karahmed@amazon.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=tim.c.chen@linux.intel.com \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome