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

Groups > linux.kernel > #1635618 > unrolled thread

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

Back to article view | Back to linux.kernel

Contents

  [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

Page 1 of 2  [1] 2  Next page →

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

[Multipart message — attachments visible in raw view] — view raw

After several recent works [1,2,3] KASLR on x86_64 was basically 
considered dead by many researchers. We have been working on an 
efficient but effective fix for this problem and found that not mapping 
the kernel space when running in user mode is the solution to this 
problem [4] (the corresponding paper [5] will be presented at ESSoS17).

With this RFC patch we allow anybody to configure their kernel with the 
flag CONFIG_KAISER to add our defense mechanism.

If there are any questions we would love to answer them.
We also appreciate any comments!

Cheers,
Daniel (+ the KAISER team from Graz University of Technology)

[1] http://www.ieee-security.org/TC/SP2013/papers/4977a191.pdf
[2] 
https://www.blackhat.com/docs/us-16/materials/us-16-Fogh-Using-Undocumented-CPU-Behaviour-To-See-Into-Kernel-Mode-And-Break-KASLR-In-The-Process.pdf
[3] 
https://www.blackhat.com/docs/us-16/materials/us-16-Jang-Breaking-Kernel-Address-Space-Layout-Randomization-KASLR-With-Intel-TSX.pdf
[4] https://github.com/IAIK/KAISER
[5] https://gruss.cc/files/kaiser.pdf

[toc] | [next] | [standalone]

#1635691

[Multipart message — attachments visible in raw view] — view raw

Sorry, missed a file in the first mail (from some code cleanup), the 
full patch is now attached.


Cheers,
Daniel

[toc] | [prev] | [next] | [standalone]

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

On Thu, May 4, 2017 at 3:02 AM, Daniel Gruss
<daniel.gruss@iaik.tugraz.at> wrote:
> After several recent works [1,2,3] KASLR on x86_64 was basically considered
> dead by many researchers. We have been working on an efficient but effective
> fix for this problem and found that not mapping the kernel space when
> running in user mode is the solution to this problem [4] (the corresponding
> paper [5] will be presented at ESSoS17).
>
> With this RFC patch we allow anybody to configure their kernel with the flag
> CONFIG_KAISER to add our defense mechanism.
>
> If there are any questions we would love to answer them.
> We also appreciate any comments!
>
> Cheers,
> Daniel (+ the KAISER team from Graz University of Technology)
>
> [1] http://www.ieee-security.org/TC/SP2013/papers/4977a191.pdf
> [2]
> https://www.blackhat.com/docs/us-16/materials/us-16-Fogh-Using-Undocumented-CPU-Behaviour-To-See-Into-Kernel-Mode-And-Break-KASLR-In-The-Process.pdf
> [3]
> https://www.blackhat.com/docs/us-16/materials/us-16-Jang-Breaking-Kernel-Address-Space-Layout-Randomization-KASLR-With-Intel-TSX.pdf
> [4] https://github.com/IAIK/KAISER
> [5] https://gruss.cc/files/kaiser.pdf
>
>

Please read the documentation on submitting patches [1] and coding style [2].

I have two questions:

 - How this approach prevent the hardware attacks you mentioned? You
still have to keep a part of _text in the pagetable and an attacker
could discover it no? (and deduce the kernel base address). You also
need to make it clear that btb attacks are still possible.
 - What is the perf impact?

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-style.rst

Thanks,
-- 
Thomas

[toc] | [prev] | [next] | [standalone]

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

On 04.05.2017 17:28, Thomas Garnier wrote:
> Please read the documentation on submitting patches [1] and coding style [2].

I will have a closer look at that.

>  - How this approach prevent the hardware attacks you mentioned? You
> still have to keep a part of _text in the pagetable and an attacker
> could discover it no? (and deduce the kernel base address).

These parts are moved to a different section (.user_mapped) which is at 
a possibly predictable location - the location of the randomized parts 
of the kernel is independent of the location of .user_mapped.
The code/data footprint for .user_mapped is quite small, helping to 
reduce or eliminate the attack surface...

> You also need to make it clear that btb attacks are still possible.

By just increasing the KASLR randomization range, btb attacks can be 
mitigated (for free).

>  - What is the perf impact?

It will vary for different machines. We have promising results (<1%) for 
an i7-6700K with representative benchmarks. However, for older systems 
or for workloads with a lot of pressure on some TLB levels, the 
performance may be much worse.

[toc] | [prev] | [next] | [standalone]

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

On Fri, May 5, 2017 at 1:23 AM, Daniel Gruss
<daniel.gruss@iaik.tugraz.at> wrote:
>
> On 04.05.2017 17:28, Thomas Garnier wrote:
>>
>> Please read the documentation on submitting patches [1] and coding style [2].
>
>
> I will have a closer look at that.
>
>>  - How this approach prevent the hardware attacks you mentioned? You
>> still have to keep a part of _text in the pagetable and an attacker
>> could discover it no? (and deduce the kernel base address).
>
>
> These parts are moved to a different section (.user_mapped) which is at a possibly predictable location - the location of the randomized parts of the kernel is independent of the location of .user_mapped.
> The code/data footprint for .user_mapped is quite small, helping to reduce or eliminate the attack surface...
>

If I get it right, it means you can leak the per-cpu address instead
of the kernel. Correct? That would be a problem because you can
elevate privilege by overwriting per-cpu variables. Leaking this
address means also defeating KASLR memory randomization [3] (cf paper
in the commit).

In theory you could put the code in the fixmap but you still have the
per-cpu variables and changing that is hard.

[3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=021182e52fe01c1f7b126f97fd6ba048dc4234fd

>> You also need to make it clear that btb attacks are still possible.
>
>
> By just increasing the KASLR randomization range, btb attacks can be mitigated (for free).

Correct, I hope we can do that.

>
>>  - What is the perf impact?
>
>
> It will vary for different machines. We have promising results (<1%) for an i7-6700K with representative benchmarks. However, for older systems or for workloads with a lot of pressure on some TLB levels, the performance may be much worse.

I think including performance data in both cases would be useful.


-- 
Thomas

[toc] | [prev] | [next] | [standalone]

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

On 2017-05-05 17:47, Thomas Garnier wrote:
> On Fri, May 5, 2017 at 1:23 AM, Daniel Gruss
> <daniel.gruss@iaik.tugraz.at> wrote:
>> 
>> On 04.05.2017 17:28, Thomas Garnier wrote:
>>> 
>>> Please read the documentation on submitting patches [1] and coding 
>>> style [2].
>> 
>> 
>> I will have a closer look at that.
>> 
>>>  - How this approach prevent the hardware attacks you mentioned? You
>>> still have to keep a part of _text in the pagetable and an attacker
>>> could discover it no? (and deduce the kernel base address).
>> 
>> 
>> These parts are moved to a different section (.user_mapped) which is 
>> at a possibly predictable location - the location of the randomized 
>> parts of the kernel is independent of the location of .user_mapped.
>> The code/data footprint for .user_mapped is quite small, helping to 
>> reduce or eliminate the attack surface...
>> 
> 
> If I get it right, it means you can leak the per-cpu address instead
> of the kernel. Correct? That would be a problem because you can
> elevate privilege by overwriting per-cpu variables. Leaking this
> address means also defeating KASLR memory randomization [3] (cf paper
> in the commit).
> 
> In theory you could put the code in the fixmap but you still have the
> per-cpu variables and changing that is hard.
> 
> [3]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=021182e52fe01c1f7b126f97fd6ba048dc4234fd

(Chiming in here, since we worked on something similar)

Assuming that their patch indeed leaks per-cpu addresses.. it might not 
necessarily
be required to change it. Since an adversary has to leak the per-cpu 
addresses
based on timing information you can work around that by inserting dummy 
entries
into the user mappings, with the goal of creating multiple candidate 
addresses
that show an identical measurement. For instance, you can create one 
entry for
every possible KASLR slot.


>>> You also need to make it clear that btb attacks are still possible.
>> 
>> 
>> By just increasing the KASLR randomization range, btb attacks can be 
>> mitigated (for free).
> 
> Correct, I hope we can do that.
> 
>> 
>>>  - What is the perf impact?
>> 
>> 
>> It will vary for different machines. We have promising results (<1%) 
>> for an i7-6700K with representative benchmarks. However, for older 
>> systems or for workloads with a lot of pressure on some TLB levels, 
>> the performance may be much worse.
> 
> I think including performance data in both cases would be useful.

Best,
David

[toc] | [prev] | [next] | [standalone]

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

On 2017-05-06 06:02, David Gens wrote:
> Assuming that their patch indeed leaks per-cpu addresses.. it might not
> necessarily
> be required to change it.

I think we're not leaking them (unless we still have some bug in our 
code). The basic idea is that any part that is required for the context 
switch is at a fixed location (unrelated to the location of code / data 
/ per-cpu data / ...) and thus does not reveal any randomized offsets. 
Then the attacker cannot gain any knowledge through the side channel 
anymore.
For any attack the attacker could then only use the few KBs of memory 
that cannot be unmapped because of the way x86 works. Hardening these 
few KBs seems like an easier task than doing the same for the entire kernel.

(The best solution would of course be Intel introducing CR3A and CR3B 
just like ARM has TTBR0 and TTBR1 - on ARM this entirely prevents any 
prefetch / double-fault side-channel attacks.)

[toc] | [prev] | [next] | [standalone]

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

Hi,

On Sat, May 06, 2017 at 10:38:23AM +0200, Daniel Gruss wrote:
> On 2017-05-06 06:02, David Gens wrote:
> >Assuming that their patch indeed leaks per-cpu addresses.. it might not
> >necessarily
> >be required to change it.
> 
> I think we're not leaking them (unless we still have some bug in our code).
> The basic idea is that any part that is required for the context switch is
> at a fixed location (unrelated to the location of code / data / per-cpu data
> / ...) and thus does not reveal any randomized offsets. Then the attacker
> cannot gain any knowledge through the side channel anymore.
> For any attack the attacker could then only use the few KBs of memory that
> cannot be unmapped because of the way x86 works. Hardening these few KBs
> seems like an easier task than doing the same for the entire kernel.
> 
> (The best solution would of course be Intel introducing CR3A and CR3B just
> like ARM has TTBR0 and TTBR1 - on ARM this entirely prevents any prefetch /
> double-fault side-channel attacks.)

While it may be the case that in practice ARM systems do not have such a
side channel, I think that it is erroneous to believe that the
architectural TTBR{0,1} split ensures this.

The use of TTBR0 for user and TTBR1 for kernel is entirely a SW policy,
and not an architectural requirement. It is possible to map data in
TTBR1 which is accessible to userspace, and data in TTBR0 which is only
accessible by the kernel. In either case, this is determined by the page
tables themselves.

Given this, I think that the statements in the KAISER paper regarding
the TTBRs (in section 2.1) are not quite right. Architecturally,
permission checks and lookups cannot be elided based on the TTBR used.

Having two TTBRs does make it simpler to change the user/kernel address
spaces independently, however.

Thanks,
Mark.

[toc] | [prev] | [next] | [standalone]

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

> While it may be the case that in practice ARM systems do not have such a
> side channel, I think that it is erroneous to believe that the
> architectural TTBR{0,1} split ensures this.
>
> The use of TTBR0 for user and TTBR1 for kernel is entirely a SW policy,
> and not an architectural requirement. It is possible to map data in
> TTBR1 which is accessible to userspace, and data in TTBR0 which is only
> accessible by the kernel. In either case, this is determined by the page
> tables themselves.

Absolutely right, but TTBR0 and TTBR1 are usually used in this way.

> Given this, I think that the statements in the KAISER paper regarding
> the TTBRs (in section 2.1) are not quite right. Architecturally,
> permission checks and lookups cannot be elided based on the TTBR used.

As we say in section 2.1, they are "typically" used in this way, and this prevents the attacks. Not just the presence of 
a second register, but the way how the two registers are used to split the translation tables for user and kernel.

[toc] | [prev] | [next] | [standalone]

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

On Mon, May 08, 2017 at 12:51:27PM +0200, Daniel Gruss wrote:
> >While it may be the case that in practice ARM systems do not have such a
> >side channel, I think that it is erroneous to believe that the
> >architectural TTBR{0,1} split ensures this.
> >
> >The use of TTBR0 for user and TTBR1 for kernel is entirely a SW policy,
> >and not an architectural requirement. It is possible to map data in
> >TTBR1 which is accessible to userspace, and data in TTBR0 which is only
> >accessible by the kernel. In either case, this is determined by the page
> >tables themselves.
> 
> Absolutely right, but TTBR0 and TTBR1 are usually used in this way.

Sure; if we consider Linux, while userspace is executing, TTBR1 will
(only) contain kernel page tables and TTBR0 will (only) contain user
page tables.

However, as this is not an architectural requirement, the CPU cannot
know that a user access that gets translated via TTBR1 will fault, and
at some point must determine the permissions from the page tables as
required by the architecture.

> >Given this, I think that the statements in the KAISER paper regarding
> >the TTBRs (in section 2.1) are not quite right. Architecturally,
> >permission checks and lookups cannot be elided based on the TTBR used.
> 
> As we say in section 2.1, they are "typically" used in this way, and
> this prevents the attacks. Not just the presence of a second
> register, but the way how the two registers are used to split the
> translation tables for user and kernel.

In practice, while userspace is executing, TTBR1 still points to kernel
page tables. If a user program attempts to access an address mapped via
TTBR1, the CPU has to attempt this translation via the TTBR1 page tables
and/or associated TLB entries.

Specifically, I think this does not align with the statement in 2.1
regarding the two TTBRs:

  This simplifies privilege checks and does not require any address
  translation for invalid memory accesses and thus no cache lookups.

... since the use of the TTBRs is orthogonal to privilege checks and/or
the design of the TLBs.

Thanks,
Mark.

[toc] | [prev] | [next] | [standalone]

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

On 08.05.2017 15:22, Mark Rutland wrote:
> Specifically, I think this does not align with the statement in 2.1
> regarding the two TTBRs:
>
>   This simplifies privilege checks and does not require any address
>   translation for invalid memory accesses and thus no cache lookups.
>
> ... since the use of the TTBRs is orthogonal to privilege checks and/or
> the design of the TLBs.

Ok, this is a good point, we will try to clarify this in the paper.

[toc] | [prev] | [next] | [standalone]

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

On 06.05.2017 10:38, Daniel Gruss wrote:
> On 2017-05-06 06:02, David Gens wrote:
>> Assuming that their patch indeed leaks per-cpu addresses.. it might not
>> necessarily
>> be required to change it.
>
> I think we're not leaking them (unless we still have some bug in our code).

Just to correct my answer here as well: Although we experimented with fixed mappings for per-cpu addresses, the current 
patch does not incorporate this yet, so it indeed still leaks. However, it is not a severe problem. The mapping of the 
required (per-cpu) variables would be at a fixed location in the user CR3, instead of the ones that are used in the kernel.

[toc] | [prev] | [next] | [standalone]

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

On Mon, May 8, 2017 at 6:53 AM, Daniel Gruss
<daniel.gruss@iaik.tugraz.at> wrote:
> On 06.05.2017 10:38, Daniel Gruss wrote:
>>
>> On 2017-05-06 06:02, David Gens wrote:
>>>
>>> Assuming that their patch indeed leaks per-cpu addresses.. it might not
>>> necessarily
>>> be required to change it.
>>
>>
>> I think we're not leaking them (unless we still have some bug in our
>> code).
>
>
> Just to correct my answer here as well: Although we experimented with fixed
> mappings for per-cpu addresses, the current patch does not incorporate this
> yet, so it indeed still leaks. However, it is not a severe problem. The
> mapping of the required (per-cpu) variables would be at a fixed location in
> the user CR3, instead of the ones that are used in the kernel.

Why do you think it should be at a fixed location in the user CR3? I
see that you just mirror the entries. You also mirror
__entry_text_start / __entry_text_end which is part of the binary so
will leak the base address of the kernel. Maybe I am missing
something.

-- 
Thomas

[toc] | [prev] | [next] | [standalone]

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

On 08.05.2017 16:09, Thomas Garnier wrote:
>> Just to correct my answer here as well: Although we experimented with fixed
>> mappings for per-cpu addresses, the current patch does not incorporate this
>> yet, so it indeed still leaks. However, it is not a severe problem. The
>> mapping of the required (per-cpu) variables would be at a fixed location in
>> the user CR3, instead of the ones that are used in the kernel.
>
> Why do you think it should be at a fixed location in the user CR3? I
> see that you just mirror the entries. You also mirror
> __entry_text_start / __entry_text_end which is part of the binary so
> will leak the base address of the kernel. Maybe I am missing
> something.

As I said, the current patch does not incorporate this yet, so yes, this part currently still leaks because we did not 
implement it yet.

[toc] | [prev] | [next] | [standalone]

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

On 05.05.2017 10:23, Daniel Gruss wrote:
>>  - How this approach prevent the hardware attacks you mentioned? You
>> still have to keep a part of _text in the pagetable and an attacker
>> could discover it no? (and deduce the kernel base address).
>
> These parts are moved to a different section (.user_mapped) which is at a possibly predictable location - the location
> of the randomized parts of the kernel is independent of the location of .user_mapped.
> The code/data footprint for .user_mapped is quite small, helping to reduce or eliminate the attack surface...

We just discussed that in our group again: although we experimented with this part, it's not yet included in the patch. 
The solution we sketched is, as I wrote, we map the required (per-thread) variables in the user CR3 to a fixed location 
in memory. During the context switch, only this fixed part remains mapped but not the randomized pages. This is not a 
lot of work, because it's just mapping a few more pages and fixing a 1 or 2 lines in the context switch.

[toc] | [prev] | [next] | [standalone]

#1635853

On Thu, May 04, 2017 at 12:02:47PM +0200, Daniel Gruss wrote:
> After several recent works [1,2,3] KASLR on x86_64 was basically considered
> dead by many researchers. We have been working on an efficient but effective
> fix for this problem and found that not mapping the kernel space when
> running in user mode is the solution to this problem [4] (the corresponding
> paper [5] will be presented at ESSoS17).

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?

[toc] | [prev] | [next] | [standalone]

#1636218

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.

[toc] | [prev] | [next] | [standalone]

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

> Just did a quick test on my main KVM host, a 8 core Intel(R) Xeon(R)
> CPU E3-1240 V2.
> KVM guests are 4.10 w/o CONFIG_KAISER and kvmconfig without CONFIG_PARAVIRT.
> Building a defconfig kernel within that guests is about 10% slower
> when CONFIG_KAISER
> is enabled.

Thank you for testing it! :)

> Is this expected?

It sounds plausible. First, I would expect any form of virtualization to 
increase the overhead. Second, for the processor (Ivy Bridge), I would 
have expected even higher performance overheads. KAISER utilizes very 
recent performance improvements in Intel processors...

> If it helps I can redo the same test also on bare metal.

I'm not sure how we proceed here and if this would help, because I don't 
know what everyone expects.
KAISER definitely introduces an overhead, no doubt about that. How much 
overhead it is depends on the specific hardware and may be very little 
on recent architectures and more on older machines.
We are not proposing to enable KAISER by default, but to provide the 
config option to allow easy integration into hardened kernels where 
performance overheads may be acceptable (which depends on the specific 
use case and the specific hardware).

[toc] | [prev] | [next] | [standalone]

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

Daniel,

Am 07.05.2017 um 23:45 schrieb Daniel Gruss:
>> Just did a quick test on my main KVM host, a 8 core Intel(R) Xeon(R)
>> CPU E3-1240 V2.
>> KVM guests are 4.10 w/o CONFIG_KAISER and kvmconfig without CONFIG_PARAVIRT.
>> Building a defconfig kernel within that guests is about 10% slower
>> when CONFIG_KAISER
>> is enabled.
> 
> Thank you for testing it! :)
> 
>> Is this expected?
> 
> It sounds plausible. First, I would expect any form of virtualization to increase the overhead. Second, for the processor (Ivy Bridge), I would have expected even higher
> performance overheads. KAISER utilizes very recent performance improvements in Intel processors...

Ahh, *very* recent is the keyword then. ;)
I was a bit confused since in your paper the overhead is less than 1%.

What platforms did you test?
i.e. how does it perform on recent AMD systems?

Thanks,
//richard

[toc] | [prev] | [next] | [standalone]

#1637099 — Re: [kernel-hardening] 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.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.kernel

csiph-web