|
Message-ID: <8aecf7d4-9767-5367-1bc0-75fbd4b17e46@iaik.tugraz.at> 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.