From mboxrd@z Thu Jan  1 00:00:00 1970
Return-path: <ak@linux.intel.com>
Received: from mga12.intel.com ([192.55.52.136])
	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 1fBRoe-0000Hf-PT
	for speck@linutronix.de; Wed, 25 Apr 2018 23:19:05 +0200
Date: Wed, 25 Apr 2018 14:19:01 -0700
From: Andi Kleen <ak@linux.intel.com>
Subject: [MODERATED] Re: [PATCH 1/6] Patch 1
Message-ID: <20180425211901.GN14273@tassilo.jf.intel.com>
References: <20180425032932.31562-1-andi@firstfloor.org>
 <alpine.LFD.2.21.999.1804250841450.19245@i7.lan>
 <20180425160654.GH14273@tassilo.jf.intel.com>
 <alpine.LFD.2.21.999.1804251019230.19245@i7.lan>
 <20180425173619.GJ14273@tassilo.jf.intel.com>
 <alpine.LFD.2.21.999.1804251050570.31078@i7.lan>
 <20180425181152.GK14273@tassilo.jf.intel.com>
 <alpine.LFD.2.21.999.1804251114010.31078@i7.lan>
 <20180425185140.GL14273@tassilo.jf.intel.com>
 <alpine.LFD.2.21.999.1804251313340.3798@i7.lan>
MIME-Version: 1.0
In-Reply-To: <alpine.LFD.2.21.999.1804251313340.3798@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 01:15:35PM -0700, speck for Linus Torvalds wrote:
> On Wed, 25 Apr 2018, speck for Andi Kleen wrote:
> > 
> > This doesn't help unfortunately because it could also leak data inside
> > the guest. If skipping EPT causes the PA to point to some other page
> > inside the same guest you can leak that data. And that other page might
> > be owned by the kernel or by some other process.
> 
> Do you even read what I write?
> 
> THAT'S EXACTLY WHAT I TALKED ABOUT IN THE REST OF THE EMAIL.

Ok so I reread what you wrote. I think you're saying it's not a problem
because it's too hard to know what the other page is?

I can think of various ways around this:

Assume the attacker process owns most of the memory and
the attacked process is very small. It fills its own memory
with a known pattern. Then it checks against that pattern.
If it's not the pattern it's someone elses. 

Or it does the mprotect attack on a lot of different pages
that it cycles through, and tries on each of them, looking
for some known pattern?

Or the attacker uses memory pressure to force another 
process to cycle through a lot of memory, and always
retries inbetween until it sees some known pattern.

Considering all these cases, do you still say that mprotect does
not need to be mitigated?

It would seem very risky to me.

BTW people like Amazon care actually a lot about
security inside their guests.

-Andi