From mboxrd@z Thu Jan  1 00:00:00 1970
Return-path: <ak@linux.intel.com>
Received: from mga04.intel.com ([192.55.52.120])
	by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256)
	(Exim 4.80)
	(envelope-from <ak@linux.intel.com>)
	id 1fBMwh-0004En-F5
	for speck@linutronix.de; Wed, 25 Apr 2018 18:07:03 +0200
Date: Wed, 25 Apr 2018 09:06:54 -0700
From: Andi Kleen <ak@linux.intel.com>
Subject: [MODERATED] Re: [PATCH 1/6] Patch 1
Message-ID: <20180425160654.GH14273@tassilo.jf.intel.com>
References: <20180425032932.31562-1-andi@firstfloor.org>
 <alpine.LFD.2.21.999.1804250841450.19245@i7.lan>
MIME-Version: 1.0
In-Reply-To: <alpine.LFD.2.21.999.1804250841450.19245@i7.lan>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: speck@linutronix.de
List-ID: <speck.linutronix.de>

On Wed, Apr 25, 2018 at 08:51:09AM -0700, speck for Linus Torvalds wrote:
> 
> 
> On Tue, 24 Apr 2018, speck for Andi Kleen wrote:
> > 
> > This patch addresses the second case. The page is swapped out and
> > the PTE has been replaced with a swap entry.  It could also
> > contain a migration or poison entry, which have the same format.
> 
> NAK NAK NAK.
> 
> Why is this doing the idiotic __swp_stop_mask, when I told multiple people 
> not to do that, and when I've already seen the patch (from Michal Hocko?) 
> that did the much simpler approach of unconditionally just inverting all 
> the 'offset' bits.

We looked at it, but your invert approach is broken if there is any MMIO
space between MAX_PA/2 ... MAX_PA that is ever mapped to ring 3. 

And we cannot rule that out.

In this case the inverted bit would start pointing to valid memory, 
so everything would become attackable.

So yes the more complicated patches are needed.

-Andi