[MODERATED] Re: L1D-Fault KVM mitigation

[Jon Masters <jcm@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2425 bytes --]

On 04/24/2018 07:16 AM, speck for David Woodhouse wrote:
> On Tue, 2018-04-24 at 13:04 +0200, speck for Peter Zijlstra wrote:
>> Not sure I'm following. The above assumes a sibling is running a
>> VCPU of another VM, right? But it could equally well run any regular
>> old task (including idle).

>> So only pausing siblings in VMX mode wouldn't help anything. The
>> !VMX tasks could still be loading stuff into L1.

> Er, yeah... I may have briefly forgotten that some people sometimes
> run actual userspace, not just VM guests.

:)

More than once over the past few months, I've pointed out that Annapurna
was the right way to go. Personally, I think the only possible way to
make any of this safe is by moving "all" userspace off host like AMZ.

> It's ring 3 *and* VMX non-root which would need to be paused on HT
> siblings. And it would need to be triggered on any transition back
> into the kernel from userspace too, not just vmexit. Which makes it a
> little bit harder.

The additional ucode hack (pausing the sibling thread) has been
discussed at some length already. It's a good idea, except for the host
side as you note, and there we have all manner of interrupts to handle.
In the case of a traditional OS on the host, that's a lot of code
happily pulling secrets into the L1 and lots of paths to track if we
wanted to do like one of the others (dunno if I can say who, but someone
is tracking all secrets loaded into the L1 and scrubbing them after, but
they also refactored enough other stuff to make that just about work).

On our end, we've discussed automatic handling at boot along the lines
that have been pondered this morning here. The problem is that you don't
want to penalize until people run KVM, and you don't want to them hot
unplug or do crazy things that might affect tunings (I already got shot
down, rightly, for suggesting that one). So, instead, it's going to have
to be messaging, and maybe tainting as insecure of some kind.

I've requested that RHEL's installer be modified to effectively add a
checkbox that defaults to enabled but very prominently offers to disable
HT if you're using virtualization. We'll then need some guidance
coordinated across the industry that for total security (even in the
face of some of the gang scheduling proposals) you need to !HT.

Jon.

-- 
Computer Architect | Sent from my Fedora powered laptop