From: Daniel Gruss <daniel.gruss@iaik.tugraz.at>
To: Christoph Hellwig <hch@infradead.org>
Cc: kernel list <linux-kernel@vger.kernel.org>,
<kernel-hardening@lists.openwall.com>,
"clementine.maurice@iaik.tugraz.at"
<clementine.maurice@iaik.tugraz.at>,
"moritz.lipp@iaik.tugraz.at" <moritz.lipp@iaik.tugraz.at>,
Michael Schwarz <michael.schwarz@iaik.tugraz.at>,
Richard Fellner <richard.fellner@student.tugraz.at>,
<kirill.shutemov@linux.intel.com>,
"Ingo Molnar" <mingo@kernel.org>,
"anders.fogh@gdata-adan.de" <anders.fogh@gdata-adan.de>
Subject: Re: [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode
Date: Fri, 5 May 2017 09:40:05 +0200 [thread overview]
Message-ID: <f9a4e8ed-1b22-0d73-924c-f5bb1e18ba93@iaik.tugraz.at> (raw)
In-Reply-To: <20170504154717.GA24353@infradead.org>
On 04.05.2017 17:47, Christoph Hellwig wrote:
> I'll try to read the paper. In the meantime: how different is your
> approach from then one here?
>
> https://lwn.net/Articles/39283/
>
> and how different is the performance impact?
The approach sounds very similar, but we have fewer changes because we
don't want to change memory allocation but only split the virtual memory
- everything can stay where it is.
We found that the CR3 switch seems to be significantly improved in
modern microarchitectures (we performed our performance tests on a
Skylake i7-6700K). We think the TLB maybe uses the full CR3 base address
as a tag, relaxing the necessity of flushing the entire TLB upon CR3
updates a bit.
Direct runtime overhead is switching the CR3, but that's it.
Indirectly, we're potentially increasing the number of TLB entries that
are required on one or the other level of the TLB. For TLB-intense tasks
this might lead to more significant performance penalties.
I'm sure the overhead on older systems is larger than on recent systems.
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Gruss <daniel.gruss@iaik.tugraz.at>
To: Christoph Hellwig <hch@infradead.org>
Cc: kernel list <linux-kernel@vger.kernel.org>,
kernel-hardening@lists.openwall.com,
"clementine.maurice@iaik.tugraz.at"
<clementine.maurice@iaik.tugraz.at>,
"moritz.lipp@iaik.tugraz.at" <moritz.lipp@iaik.tugraz.at>,
Michael Schwarz <michael.schwarz@iaik.tugraz.at>,
Richard Fellner <richard.fellner@student.tugraz.at>,
kirill.shutemov@linux.intel.com, Ingo Molnar <mingo@kernel.org>,
"anders.fogh@gdata-adan.de" <anders.fogh@gdata-adan.de>
Subject: [kernel-hardening] Re: [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode
Date: Fri, 5 May 2017 09:40:05 +0200 [thread overview]
Message-ID: <f9a4e8ed-1b22-0d73-924c-f5bb1e18ba93@iaik.tugraz.at> (raw)
In-Reply-To: <20170504154717.GA24353@infradead.org>
On 04.05.2017 17:47, Christoph Hellwig wrote:
> I'll try to read the paper. In the meantime: how different is your
> approach from then one here?
>
> https://lwn.net/Articles/39283/
>
> and how different is the performance impact?
The approach sounds very similar, but we have fewer changes because we
don't want to change memory allocation but only split the virtual memory
- everything can stay where it is.
We found that the CR3 switch seems to be significantly improved in
modern microarchitectures (we performed our performance tests on a
Skylake i7-6700K). We think the TLB maybe uses the full CR3 base address
as a tag, relaxing the necessity of flushing the entire TLB upon CR3
updates a bit.
Direct runtime overhead is switching the CR3, but that's it.
Indirectly, we're potentially increasing the number of TLB entries that
are required on one or the other level of the TLB. For TLB-intense tasks
this might lead to more significant performance penalties.
I'm sure the overhead on older systems is larger than on recent systems.
next prev parent reply other threads:[~2017-05-05 7:41 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-04 10:02 [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode Daniel Gruss
2017-05-04 10:02 ` [kernel-hardening] " Daniel Gruss
2017-05-04 12:26 ` Daniel Gruss
2017-05-04 12:26 ` [kernel-hardening] " Daniel Gruss
2017-05-04 15:28 ` [kernel-hardening] " Thomas Garnier
2017-05-04 15:28 ` Thomas Garnier
2017-05-05 8:23 ` Daniel Gruss
2017-05-05 8:23 ` Daniel Gruss
2017-05-05 15:47 ` Thomas Garnier
2017-05-05 15:47 ` Thomas Garnier
2017-05-06 4:02 ` David Gens
2017-05-06 8:38 ` Daniel Gruss
2017-05-06 8:38 ` Daniel Gruss
2017-05-08 10:21 ` Mark Rutland
2017-05-08 10:51 ` Daniel Gruss
2017-05-08 10:51 ` Daniel Gruss
2017-05-08 13:22 ` Mark Rutland
2017-05-08 13:43 ` Daniel Gruss
2017-05-08 13:43 ` Daniel Gruss
2017-05-08 13:53 ` Daniel Gruss
2017-05-08 13:53 ` Daniel Gruss
2017-05-08 14:09 ` Thomas Garnier
2017-05-08 14:19 ` Daniel Gruss
2017-05-08 14:19 ` Daniel Gruss
2017-05-08 13:23 ` Daniel Gruss
2017-05-08 13:23 ` Daniel Gruss
2017-05-04 15:47 ` Christoph Hellwig
2017-05-04 15:47 ` [kernel-hardening] " Christoph Hellwig
2017-05-05 7:40 ` Daniel Gruss [this message]
2017-05-05 7:40 ` Daniel Gruss
2017-05-07 20:20 ` Richard Weinberger
2017-05-07 20:20 ` Richard Weinberger
2017-05-07 21:45 ` Daniel Gruss
2017-05-07 21:45 ` Daniel Gruss
2017-05-07 22:02 ` Richard Weinberger
2017-05-07 22:02 ` Richard Weinberger
2017-05-07 22:18 ` Daniel Gruss
2017-05-07 22:18 ` Daniel Gruss
2017-05-09 14:44 ` [kernel-hardening] Re: [RFC, PATCH] x86_64: KAISER - do not mapkernel " Fogh, Anders
2017-05-09 14:44 ` Fogh, Anders
2017-05-09 14:57 ` Richard Weinberger
2017-05-09 14:57 ` Richard Weinberger
2017-05-09 15:30 ` Rik van Riel
2017-05-09 15:30 ` Rik van Riel
2017-10-31 23:28 ` Dave Hansen
2017-10-31 23:28 ` Dave Hansen
2017-05-05 15:49 ` [kernel-hardening] [RFC, PATCH] x86_64: KAISER - do not map kernel " Jann Horn
2017-05-05 15:49 ` Jann Horn
2017-05-05 15:53 ` Jann Horn
2017-05-05 15:53 ` Jann Horn
2017-05-06 8:28 ` Daniel Gruss
2017-05-06 8:28 ` Daniel Gruss
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f9a4e8ed-1b22-0d73-924c-f5bb1e18ba93@iaik.tugraz.at \
--to=daniel.gruss@iaik.tugraz.at \
--cc=anders.fogh@gdata-adan.de \
--cc=clementine.maurice@iaik.tugraz.at \
--cc=hch@infradead.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.schwarz@iaik.tugraz.at \
--cc=mingo@kernel.org \
--cc=moritz.lipp@iaik.tugraz.at \
--cc=richard.fellner@student.tugraz.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.