[MODERATED] Re: Updated L1TF native OS patch

[Michal Hocko <mhocko@suse.com>]

On Wed 02-05-18 08:07:39, speck for Andi Kleen wrote:
> > I have to confess that I do not understand the thread model for
> > PROT_NONE patch though. The mitigation _has_ to be done on the
> > VM layer otherwise we are screwed. So why should we even bother
> > and make the code even more kludgy?
> 
> It has to be done in both layers. One is between guests/hosts,
> and the other is inside the guest.
> 
> Here's an example:
> 
> You have physical pages 1 2. They get mapped into a guest as 
> GPA 1 -> PA 2
> GPA 2 -> PA 1
> through EPT. 
> 
> The L1TF speculation ignores the EPT remapping.
> 
> Now the guest kernel maps GPA 1 to process A and GPA 2 to process B,
> and they belong to different users and should be isolated.
> 
> If A sets the GPA 1 PA 2 page to PROT_NONE to bypass the EPT remapping
> and gets read access to the underlying physical page. Which
> in this case points to PA 2, so it can read process B's data,
> if it happened to be in L1.
> 
> So we broke isolation inside the guest. 

OK, I see. Thanks for the clarification. I guess the changelog could be
more explicit about thits.

> There's nothing the hypervisor can do about this. This
> mitigation has to be done in the guest.
> 
> > Patch 3 seems reasonable but I do not feel confident enough to give my
> > ack because I simply have no idea whether some obscure HW depends on the
> > zero page.
> 
> Can you expand? How should hardware depend on it?
> 
> It certainly cannot write to it, and even reading would be dubious because
> the contents are undefined.

Yeah, reads is what I would be worried about. I do not have any specific
offender in mind but this is really hard to check for.
-- 
Michal Hocko
SUSE Labs