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
