Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH v2 5/8] x86/speculation: Add basic support for IBPB
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
References: <1516528149-9370-1-git-send-email-dwmw@amazon.co.uk>
 <1516528149-9370-6-git-send-email-dwmw@amazon.co.uk>
 <20180121180621.ufmc5m7nr6v4tjvc@pd.tnic>
 <31c52131-5f7a-8af0-3092-5fc9e322a734@amazon.com>
 <20180121190145.uuk3xizxejckth5s@pd.tnic>
 <1516563060.9814.52.camel@infradead.org>
 <f9141600-45e4-999a-e997-05eeb56cda29@citrix.com>
 <1516565047.9814.59.camel@infradead.org>
From:   Andrew Cooper <andrew.cooper3@citrix.com>
Message-ID: <648c29c2-eeda-f34b-e7ea-1be59b60a6e5@citrix.com>
Date:   Sun, 21 Jan 2018 20:19:43 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <1516565047.9814.59.camel@infradead.org>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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