[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 8 May 2017 00:18:14 +0200
From: Daniel Gruss <daniel.gruss@...k.tugraz.at>
To: Richard Weinberger <richard@....at>
CC: Christoph Hellwig <hch@...radead.org>,
kernel list
<linux-kernel@...r.kernel.org>,
"kernel-hardening@...ts.openwall.com"
<kernel-hardening@...ts.openwall.com>,
"clementine.maurice@...k.tugraz.at"
<clementine.maurice@...k.tugraz.at>,
"moritz.lipp@...k.tugraz.at"
<moritz.lipp@...k.tugraz.at>,
Michael Schwarz
<michael.schwarz@...k.tugraz.at>,
Richard Fellner
<richard.fellner@...dent.tugraz.at>,
"Kirill A. Shutemov"
<kirill.shutemov@...ux.intel.com>,
Ingo Molnar <mingo@...nel.org>,
"anders.fogh@...ta-adan.de" <anders.fogh@...ta-adan.de>
Subject: Re: Re: [RFC, PATCH] x86_64: KAISER - do not map
kernel in user mode
On 2017-05-08 00:02, Richard Weinberger wrote:
> Ahh, *very* recent is the keyword then. ;)
> I was a bit confused since in your paper the overhead is less than 1%.
Yes, only for very recent platforms (Skylake). While working on the
paper we were surprised that we found overheads that small.
> What platforms did you test?
We tested it on multiple platforms for stability, but we only ran longer
performance tests on different Skylake i7-6700K systems we mentioned in
the paper.
> i.e. how does it perform on recent AMD systems?
Unfortunately, we don't have any AMD systems at hand. I'm also not sure
how AMD is affected by the issue in the first place. Although unlikely,
there is the possibility that the problem of KASLR information leakage
through microarchitectural side channels might be Intel-specific.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
