Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1636218

Re: [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode

From Daniel Gruss <daniel.gruss@iaik.tugraz.at>
Newsgroups linux.kernel
Subject Re: [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode
Date 2017-05-05 09:50 +0200
Message-ID <tDG9X-798-11@gated-at.bofh.it> (permalink)
References <tDm1z-24V-7@gated-at.bofh.it> <tDraV-5t6-3@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw

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.

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[RFC, PATCH] x86_64: KAISER - do not map kernel in user mode Daniel Gruss <daniel.gruss@iaik.tugraz.at> - 2017-05-04 12:20 +0200
  Re: [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode Daniel Gruss <daniel.gruss@iaik.tugraz.at> - 2017-05-04 14:30 +0200
  Re: [kernel-hardening] [RFC, PATCH] x86_64: KAISER - do not map  kernel in user mode Thomas Garnier <thgarnie@google.com> - 2017-05-04 17:30 +0200
    Re: [kernel-hardening] [RFC, PATCH] x86_64: KAISER - do not map  kernel in user mode Daniel Gruss <daniel.gruss@iaik.tugraz.at> - 2017-05-05 10:30 +0200
      Re: [kernel-hardening] [RFC, PATCH] x86_64: KAISER - do not map  kernel in user mode Thomas Garnier <thgarnie@google.com> - 2017-05-05 17:50 +0200
        Re: [kernel-hardening] [RFC, PATCH] x86_64: KAISER - do not map  kernel in user mode David Gens <david.gens@cs.tu-darmstadt.de> - 2017-05-06 06:40 +0200
          Re: [kernel-hardening] [RFC, PATCH] x86_64: KAISER - do not map  kernel in user mode Daniel Gruss <daniel.gruss@iaik.tugraz.at> - 2017-05-06 10:40 +0200
            Re: [kernel-hardening] [RFC, PATCH] x86_64: KAISER - do not map  kernel in user mode Mark Rutland <mark.rutland@arm.com> - 2017-05-08 12:30 +0200
              Re: [kernel-hardening] [RFC, PATCH] x86_64: KAISER - do not map  kernel in user mode Daniel Gruss <daniel.gruss@iaik.tugraz.at> - 2017-05-08 13:00 +0200
                Re: [kernel-hardening] [RFC, PATCH] x86_64: KAISER - do not map  kernel in user mode Mark Rutland <mark.rutland@arm.com> - 2017-05-08 15:30 +0200
                Re: [kernel-hardening] [RFC, PATCH] x86_64: KAISER - do not map  kernel in user mode Daniel Gruss <daniel.gruss@iaik.tugraz.at> - 2017-05-08 15:50 +0200
            Re: [kernel-hardening] [RFC, PATCH] x86_64: KAISER - do not map  kernel in user mode Daniel Gruss <daniel.gruss@iaik.tugraz.at> - 2017-05-08 16:00 +0200
              Re: [kernel-hardening] [RFC, PATCH] x86_64: KAISER - do not map  kernel in user mode Thomas Garnier <thgarnie@google.com> - 2017-05-08 16:20 +0200
                Re: [kernel-hardening] [RFC, PATCH] x86_64: KAISER - do not map  kernel in user mode Daniel Gruss <daniel.gruss@iaik.tugraz.at> - 2017-05-08 16:20 +0200
      Re: [kernel-hardening] [RFC, PATCH] x86_64: KAISER - do not map  kernel in user mode Daniel Gruss <daniel.gruss@iaik.tugraz.at> - 2017-05-08 15:30 +0200
  Re: [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode Christoph Hellwig <hch@infradead.org> - 2017-05-04 17:50 +0200
    Re: [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode Daniel Gruss <daniel.gruss@iaik.tugraz.at> - 2017-05-05 09:50 +0200
      Re: [kernel-hardening] Re: [RFC, PATCH] x86_64: KAISER - do not map  kernel in user mode Daniel Gruss <daniel.gruss@iaik.tugraz.at> - 2017-05-07 23:50 +0200
        Re: [kernel-hardening] Re: [RFC, PATCH] x86_64: KAISER - do not map  kernel in user mode Richard Weinberger <richard@nod.at> - 2017-05-08 00:10 +0200
          Re: [kernel-hardening] Re: [RFC, PATCH] x86_64: KAISER - do not map  kernel in user mode Daniel Gruss <daniel.gruss@iaik.tugraz.at> - 2017-05-08 00:20 +0200
            Re: [kernel-hardening] Re: [RFC, PATCH] x86_64: KAISER - do not mapkernel in user mode "Fogh, Anders" <anders.fogh@gdata-adan.de> - 2017-05-09 17:00 +0200
              Re: [kernel-hardening] Re: [RFC, PATCH] x86_64: KAISER - do not  mapkernel in user mode Richard Weinberger <richard@nod.at> - 2017-05-09 17:00 +0200
                Re: [kernel-hardening] Re: [RFC, PATCH] x86_64: KAISER - do not  mapkernel in user mode Rik van Riel <riel@redhat.com> - 2017-05-09 17:40 +0200
      Re: [kernel-hardening] Re: [RFC, PATCH] x86_64: KAISER - do not map  kernel in user mode Richard Weinberger <richard.weinberger@gmail.com> - 2017-05-08 00:10 +0200
  Re: [kernel-hardening] [RFC, PATCH] x86_64: KAISER - do not map  kernel in user mode Jann Horn <jannh@google.com> - 2017-05-05 18:00 +0200
    Re: [kernel-hardening] [RFC, PATCH] x86_64: KAISER - do not map  kernel in user mode Daniel Gruss <daniel.gruss@iaik.tugraz.at> - 2017-05-06 10:30 +0200
  Re: [kernel-hardening] [RFC, PATCH] x86_64: KAISER - do not map  kernel in user mode Jann Horn <jannh@google.com> - 2017-05-05 18:00 +0200

csiph-web