[MODERATED] Re: [PATCH 1/1 v2] Linux patch #1

[Andi Kleen <ak@linux.intel.com>]

> I do understand your arugment, but given all the pushback you're giving to 
> the "simple" solution, I guess it's now your turn to propose how _exactly_ 
> this should be done.

Right.

I think the key missing piece is a Documentation/ file that describes
what to do, and to which KVM can point to. I'll look into this next week.

> 
> Namely, we need to make sure that
> 
> - whoever provides public VMs (cloud providers) gets the right (all) 
>   mitigations; at the same time, any performance loss that would not
>   be security-justified is a no-go

These will be using a wide variety of mitigations depending on their
circumstances (e.g. likely per core binding or some others like falling 
back to shadow page tables for UP), likely few will be 
using SMT off

They should know what they are doing.
> 
> - whoever doesn't need the mitigations (usually desktop users, but who 
>   knows) gets what they need (how do you/they figure that out easily?)

Two steps:
- do you control the guest OS?
- is the guest OS mitigated too.

Then they are safe.

It's really a simple rule: just patch and update everything you control.

If you don't control the guest OS then consider first cpuset, and then
SMT off.

> 
> - Joe The Random User, who absoluetely doesn't have a clue what either of 
>   the terms  "CPU", "cache", "speculation", "virtualization" really means
>   in the low-level technical terms, but is able to click around and use 
>   his computer (including firing up virtual machines for any purpose, as
>   that's super-trivial these days) doesn't get fully compromised 
>   immediately

It should be safe to assume they don't run untrusted gursts.

They also need to make sure to update the guest OS.

> 
> - you don't have to fine-tune this (build-time-)configuration per each and 
>   every individual system

?

-Andi