[MODERATED] Updated L1TF native OS patch

[MODERATED] Updated L1TF native OS patch

[Andi Kleen]

[no threaded cover letter because I haven't figured out how
to do that with the speck tools]

Here's a v2 of the L1TF native OS patch kit. I reworked
it based on Linus suggestions. Instead of explicit masks it now
uses inversion for swap entries and the PFN part of PROT_NONE
entries. The swap entry patch is Linus' with only minor comment
changes and some testing.

It drops supports for mitigation high MMIO. After some discussion
we decided that is too unlikely to happen, and with inversion
it is somewhat painful.

-Andi

[MODERATED] Re: Updated L1TF native OS patch

[Linus Torvalds]

On Tue, 1 May 2018, speck for Andi Kleen wrote:
> 
> Here's a v2 of the L1TF native OS patch kit.

Hmm. I got 1/6 three times, but not any of the others..

             Linus

[MODERATED] Re: Updated L1TF native OS patch

[Andi Kleen]

On Tue, May 01, 2018 at 04:59:53PM -0700, speck for Linus Torvalds wrote:
> 
> 
> On Tue, 1 May 2018, speck for Andi Kleen wrote:
> > 
> > Here's a v2 of the L1TF native OS patch kit.
> 
> Hmm. I got 1/6 three times, but not any of the others..

Sorry I had some troubles with the gpg scripting. I sent 
them manually now. Hopefully this works.

-Andi

[MODERATED] Re: Updated L1TF native OS patch

[Andi Kleen]

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

On Tue, May 01, 2018 at 05:05:12PM -0700, speck for Andi Kleen wrote:
> On Tue, May 01, 2018 at 04:59:53PM -0700, speck for Linus Torvalds wrote:
> > 
> > 
> > On Tue, 1 May 2018, speck for Andi Kleen wrote:
> > > 
> > > Here's a v2 of the L1TF native OS patch kit.
> > 
> > Hmm. I got 1/6 three times, but not any of the others..
> 
> Sorry I had some troubles with the gpg scripting. I sent 
> them manually now. Hopefully this works.

Also attaching the unencrypted mbox for easier applying etc.

-Andi

[-- Attachment #2: m --]
[-- Type: application/vnd.wolfram.mathematica.package, Size: 27485 bytes --]

[MODERATED] Re: Updated L1TF native OS patch

[Peter Zijlstra]

On Tue, May 01, 2018 at 06:21:12PM -0700, speck for Andi Kleen wrote:
> Also attaching the unencrypted mbox for easier applying etc.

I would've expected patch 1 to be two separate patches; one flipping the
fields the other flipping the bits. That's just a wee bit easier to look
at.

And patch 4's X86_FEATURE_NO_L1TF_FIX is weird, we typically have
positive flags for the fixes, see PTI, RETPOLINE and
SPEC_STORE_BYPASS_DISABLE.

Re: Updated L1TF native OS patch

[Thomas Gleixner]

On Tue, 1 May 2018, speck for Andi Kleen wrote:
> On Tue, May 01, 2018 at 05:05:12PM -0700, speck for Andi Kleen wrote:
> > On Tue, May 01, 2018 at 04:59:53PM -0700, speck for Linus Torvalds wrote:
> > > 
> > > 
> > > On Tue, 1 May 2018, speck for Andi Kleen wrote:
> > > > 
> > > > Here's a v2 of the L1TF native OS patch kit.
> > > 
> > > Hmm. I got 1/6 three times, but not any of the others..
> > 
> > Sorry I had some troubles with the gpg scripting. I sent 
> > them manually now. Hopefully this works.

What's the problem? Does that speckify-mbox script not work for you?

> Also attaching the unencrypted mbox for easier applying etc.

Remailing it right now.

Re: Updated L1TF native OS patch

[Thomas Gleixner]

On Wed, 2 May 2018, speck for Thomas Gleixner wrote:
> On Tue, 1 May 2018, speck for Andi Kleen wrote:
> > On Tue, May 01, 2018 at 05:05:12PM -0700, speck for Andi Kleen wrote:
> > > On Tue, May 01, 2018 at 04:59:53PM -0700, speck for Linus Torvalds wrote:
> > > > 
> > > > 
> > > > On Tue, 1 May 2018, speck for Andi Kleen wrote:
> > > > > 
> > > > > Here's a v2 of the L1TF native OS patch kit.
> > > > 
> > > > Hmm. I got 1/6 three times, but not any of the others..
> > > 
> > > Sorry I had some troubles with the gpg scripting. I sent 
> > > them manually now. Hopefully this works.
> 
> What's the problem? Does that speckify-mbox script not work for you?
> 
> > Also attaching the unencrypted mbox for easier applying etc.
> 
> Remailing it right now.

How on earth did you generate that mbox? There's no message ID, random
dates and whatever.

[MODERATED] Re: Updated L1TF native OS patch

[Michal Hocko]

On Tue 01-05-18 18:21:12, speck for Andi Kleen wrote:
> On Tue, May 01, 2018 at 05:05:12PM -0700, speck for Andi Kleen wrote:
> > On Tue, May 01, 2018 at 04:59:53PM -0700, speck for Linus Torvalds wrote:
> > > 
> > > 
> > > On Tue, 1 May 2018, speck for Andi Kleen wrote:
> > > > 
> > > > Here's a v2 of the L1TF native OS patch kit.
> > > 
> > > Hmm. I got 1/6 three times, but not any of the others..
> > 
> > Sorry I had some troubles with the gpg scripting. I sent 
> > them manually now. Hopefully this works.
> 
> Also attaching the unencrypted mbox for easier applying etc.

I didn't get the series so I am replying here. You can add
Acked-by: Michal Hocko <mhocko@suse.com>
for the first patch "x86, l1tf: Protect swap entries against L1TF".

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?

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.

Finaly patch 6 should at least report it truncates the swap file. Other
than that, looks good to me and you can add
Acked-by: Michal Hocko <mhocko@suse.com>

Thanks!

-- 
Michal Hocko
SUSE Labs

Re: Updated L1TF native OS patch

[Thomas Gleixner]

On Wed, 2 May 2018, speck for Michal Hocko wrote:

> On Tue 01-05-18 18:21:12, speck for Andi Kleen wrote:
> > On Tue, May 01, 2018 at 05:05:12PM -0700, speck for Andi Kleen wrote:
> > > On Tue, May 01, 2018 at 04:59:53PM -0700, speck for Linus Torvalds wrote:
> > > > 
> > > > 
> > > > On Tue, 1 May 2018, speck for Andi Kleen wrote:
> > > > > 
> > > > > Here's a v2 of the L1TF native OS patch kit.
> > > > 
> > > > Hmm. I got 1/6 three times, but not any of the others..
> > > 
> > > Sorry I had some troubles with the gpg scripting. I sent 
> > > them manually now. Hopefully this works.
> > 
> > Also attaching the unencrypted mbox for easier applying etc.
> 
> I didn't get the series so I am replying here. You can add

You might find the series by sorting the folder on delivery date. The mails
from Andi have random dates.

[MODERATED] Re: Updated L1TF native OS patch

[Michal Hocko]

On Wed 02-05-18 14:36:58, speck for Thomas Gleixner wrote:
> On Wed, 2 May 2018, speck for Michal Hocko wrote:
> 
> > On Tue 01-05-18 18:21:12, speck for Andi Kleen wrote:
> > > On Tue, May 01, 2018 at 05:05:12PM -0700, speck for Andi Kleen wrote:
> > > > On Tue, May 01, 2018 at 04:59:53PM -0700, speck for Linus Torvalds wrote:
> > > > > 
> > > > > 
> > > > > On Tue, 1 May 2018, speck for Andi Kleen wrote:
> > > > > > 
> > > > > > Here's a v2 of the L1TF native OS patch kit.
> > > > > 
> > > > > Hmm. I got 1/6 three times, but not any of the others..
> > > > 
> > > > Sorry I had some troubles with the gpg scripting. I sent 
> > > > them manually now. Hopefully this works.
> > > 
> > > Also attaching the unencrypted mbox for easier applying etc.
> > 
> > I didn't get the series so I am replying here. You can add
> 
> You might find the series by sorting the folder on delivery date. The mails
> from Andi have random dates.

Right you are! Thanks. My inbox is a complete mess after LSF and few
days vacation afterwards.

Anyway, let me know if I should re-apply to those patches or you can
incorporate the feedback from here Andi.

-- 
Michal Hocko
SUSE Labs

[MODERATED] Re: Updated L1TF native OS patch

[Andi Kleen]

On Wed, May 02, 2018 at 12:48:57PM +0200, speck for Thomas Gleixner wrote:
> On Tue, 1 May 2018, speck for Andi Kleen wrote:
> > On Tue, May 01, 2018 at 05:05:12PM -0700, speck for Andi Kleen wrote:
> > > On Tue, May 01, 2018 at 04:59:53PM -0700, speck for Linus Torvalds wrote:
> > > > 
> > > > 
> > > > On Tue, 1 May 2018, speck for Andi Kleen wrote:
> > > > > 
> > > > > Here's a v2 of the L1TF native OS patch kit.
> > > > 
> > > > Hmm. I got 1/6 three times, but not any of the others..
> > > 
> > > Sorry I had some troubles with the gpg scripting. I sent 
> > > them manually now. Hopefully this works.
> 
> What's the problem? Does that speckify-mbox script not work for you?

Yes it does, but for some reason git-send-email only started sending
the first email from the resulting mbox. But likely was
something I did wrong with git-format-patch, will check.

I'll use your speck-patchbomb alias next time. I just need
to attach the mbox file to an encrypted email there, right?

-Andi

Re: Updated L1TF native OS patch

[Thomas Gleixner]

On Wed, 2 May 2018, speck for Andi Kleen wrote:
> On Wed, May 02, 2018 at 12:48:57PM +0200, speck for Thomas Gleixner wrote:
> > On Tue, 1 May 2018, speck for Andi Kleen wrote:
> > > On Tue, May 01, 2018 at 05:05:12PM -0700, speck for Andi Kleen wrote:
> > > > On Tue, May 01, 2018 at 04:59:53PM -0700, speck for Linus Torvalds wrote:
> > > > > 
> > > > > 
> > > > > On Tue, 1 May 2018, speck for Andi Kleen wrote:
> > > > > > 
> > > > > > Here's a v2 of the L1TF native OS patch kit.
> > > > > 
> > > > > Hmm. I got 1/6 three times, but not any of the others..
> > > > 
> > > > Sorry I had some troubles with the gpg scripting. I sent 
> > > > them manually now. Hopefully this works.
> > 
> > What's the problem? Does that speckify-mbox script not work for you?
> 
> Yes it does, but for some reason git-send-email only started sending
> the first email from the resulting mbox. But likely was
> something I did wrong with git-format-patch, will check.
> 
> I'll use your speck-patchbomb alias next time. I just need
> to attach the mbox file to an encrypted email there, right?

As I said before I have not yet implemented it due to -ENOTIME.

See the other mail where I gave a speckify-gitmail script with detailed
instructions how to use it.

Thanks,

	tglx

[MODERATED] Re: Updated L1TF native OS patch

[Andi Kleen]

> 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. 

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.

-Andi

[MODERATED] Re: Updated L1TF native OS patch

[Michal Hocko]

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

[MODERATED] Re: Updated L1TF native OS patch

[Andi Kleen]

> > 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.

There's no difference for reads. The memory does not go away.
It can still read it.

The reservation just guarantees it is never used for any user data.

BTW I expect the patch to almost certainly be a noop in most cases,
because 0 should be already reserved, but I couldn't convince
myself that it happens in all cases.

I remember at least when I worked on the original x86_64 code
there was an explicit reservation, but it seems to have been
removed at some point (or at least I couldn't find it anymore)

-Andi

[MODERATED] Re: Updated L1TF native OS patch

[Michal Hocko]

On Wed 02-05-18 09:08:13, speck for Andi Kleen wrote:
> > > 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.
> 
> There's no difference for reads. The memory does not go away.
> It can still read it.
> 
> The reservation just guarantees it is never used for any user data.

Yeah, but I am not really sure some virtualization or crap HW has to
have it allocated for RO. Maybe I am too paranoid. Anyway, I am not
saying the patch is wrong, I am just not sure enough to give my ack.
-- 
Michal Hocko
SUSE Labs

[MODERATED] Re: Updated L1TF native OS patch

[Michal Hocko]

On Wed 02-05-18 14:14:20, speck for Michal Hocko 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?

Now with the thread model clarified and the patch reviewed you can add
Acked-by: Michal Hocko <mhocko@suse.com>

I still think that the changelog could be more explicit but leave the
decision on you.

-- 
Michal Hocko
SUSE Labs