Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1635618 > unrolled thread
| Started by | Daniel Gruss <daniel.gruss@iaik.tugraz.at> |
|---|---|
| First post | 2017-05-04 12:20 +0200 |
| Last post | 2017-05-05 18:00 +0200 |
| Articles | 7 on this page of 27 — 10 participants |
Back to article view | Back to linux.kernel
[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 2 of 2 — ← Prev page 1 [2]
| From | "Fogh, Anders" <anders.fogh@gdata-adan.de> |
|---|---|
| Date | 2017-05-09 17:00 +0200 |
| Subject | Re: [kernel-hardening] Re: [RFC, PATCH] x86_64: KAISER - do not mapkernel in user mode |
| Message-ID | <tFeMi-37Z-9@gated-at.bofh.it> |
| In reply to | #1637099 |
>> i.e. how does it perform on recent AMD systems? Sorry for the latency. Recent AMD is reported by Enrique Nissem to not be vulnerable to the prefetch attack. TSX attack doesn't apply to AMD. Hund, Willems & Holz wrote in 2013 that AMD was vulnerable to that attack. The BTB is almost surely working in a different manner of fashion if at all. So AMD may or may not be vulnerable to the DPF attack, but none of the modern attacks should work - at least out of the box. Best regards, Anders ____________ Virus checked by G Data MailSecurity Version: AVA 25.12310 dated 09.05.2017 Virus news: www.antiviruslab.com
[toc] | [prev] | [next] | [standalone]
| From | Richard Weinberger <richard@nod.at> |
|---|---|
| Date | 2017-05-09 17:00 +0200 |
| Subject | Re: [kernel-hardening] Re: [RFC, PATCH] x86_64: KAISER - do not mapkernel in user mode |
| Message-ID | <tFeMj-37Z-19@gated-at.bofh.it> |
| In reply to | #1638177 |
Am 09.05.2017 um 16:44 schrieb Fogh, Anders: >>> i.e. how does it perform on recent AMD systems? > > Sorry for the latency. Recent AMD is reported by Enrique Nissem to not > be vulnerable to the prefetch attack. TSX attack doesn't apply to AMD. > Hund, Willems & Holz wrote in 2013 that AMD was vulnerable to that > attack. The BTB is almost surely working in a different manner of > fashion if at all. So AMD may or may not be vulnerable to the DPF > attack, but none of the modern attacks should work - at least out of the > box. But the promoted patch will also run on AMD systems, that's why I asked for the overhead. Thanks, //richard
[toc] | [prev] | [next] | [standalone]
| From | Rik van Riel <riel@redhat.com> |
|---|---|
| Date | 2017-05-09 17:40 +0200 |
| Subject | Re: [kernel-hardening] Re: [RFC, PATCH] x86_64: KAISER - do not mapkernel in user mode |
| Message-ID | <tFfp0-3Bv-39@gated-at.bofh.it> |
| In reply to | #1638180 |
[Multipart message — attachments visible in raw view] — view raw
On Tue, 2017-05-09 at 16:57 +0200, Richard Weinberger wrote: > Am 09.05.2017 um 16:44 schrieb Fogh, Anders: > > > > i.e. how does it perform on recent AMD systems? > > > > Sorry for the latency. Recent AMD is reported by Enrique Nissem to > > not > > be vulnerable to the prefetch attack. TSX attack doesn't apply to > > AMD. > > Hund, Willems & Holz wrote in 2013 that AMD was vulnerable to that > > attack. The BTB is almost surely working in a different manner of > > fashion if at all. So AMD may or may not be vulnerable to the DPF > > attack, but none of the modern attacks should work - at least out > > of the > > box. > > But the promoted patch will also run on AMD systems, that's why I > asked > for the overhead. Well, if it is a compile time switch, and the overhead is unacceptable on everything but the very latest Intel chips, chances are the code will not be enabled in any distribution kernel. -- All rights reversed
[toc] | [prev] | [next] | [standalone]
| From | Richard Weinberger <richard.weinberger@gmail.com> |
|---|---|
| Date | 2017-05-08 00:10 +0200 |
| Subject | Re: [kernel-hardening] Re: [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode |
| Message-ID | <tECdZ-30b-41@gated-at.bofh.it> |
| In reply to | #1636218 |
Daniel, On Fri, May 5, 2017 at 9:40 AM, Daniel Gruss <daniel.gruss@iaik.tugraz.at> wrote: > I'm sure the overhead on older systems is larger than on recent systems. 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. Is this expected? If it helps I can redo the same test also on bare metal. -- Thanks, //richard
[toc] | [prev] | [next] | [standalone]
| From | Jann Horn <jannh@google.com> |
|---|---|
| Date | 2017-05-05 18:00 +0200 |
| Subject | Re: [kernel-hardening] [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode |
| Message-ID | <tDNO9-3Hm-11@gated-at.bofh.it> |
| In reply to | #1635618 |
On Fri, May 5, 2017 at 5:49 PM, Jann Horn <jannh@google.com> wrote: > On Thu, May 4, 2017 at 12:02 PM, 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! > > Why do you need this SWITCH_KERNEL_CR3_NO_STACK logic? It would > make sense if the kernel stacks weren't mapped, but if they weren't mapped, > I don't see how the entry_INT80_compat entry point could work at all - the > software interrupt itself already pushes values on the kernel stack. You could > maybe work around that using some sort of trampoline stack, but I don't see > anything like that. Am I missing something? Ah, I think I understand. The kernel stacks are mapped, but cpu_current_top_of_stack isn't, so you can't find the stack until after the CR3 switch in the syscall handler?
[toc] | [prev] | [next] | [standalone]
| From | Daniel Gruss <daniel.gruss@iaik.tugraz.at> |
|---|---|
| Date | 2017-05-06 10:30 +0200 |
| Subject | Re: [kernel-hardening] [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode |
| Message-ID | <tE3ge-5Fp-15@gated-at.bofh.it> |
| In reply to | #1636467 |
On 2017-05-05 17:53, Jann Horn wrote: > Ah, I think I understand. The kernel stacks are mapped, but > cpu_current_top_of_stack isn't, so you can't find the stack until after the CR3 > switch in the syscall handler? That's the idea. Only the absolute minimum that is required for a context switch remains mapped (+ it is mapped at an offset which does not depend on KASLR -> we do not leak the KASLR offsets).
[toc] | [prev] | [next] | [standalone]
| From | Jann Horn <jannh@google.com> |
|---|---|
| Date | 2017-05-05 18:00 +0200 |
| Subject | Re: [kernel-hardening] [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode |
| Message-ID | <tDNO9-3Hm-13@gated-at.bofh.it> |
| In reply to | #1635618 |
On Thu, May 4, 2017 at 12:02 PM, 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! Why do you need this SWITCH_KERNEL_CR3_NO_STACK logic? It would make sense if the kernel stacks weren't mapped, but if they weren't mapped, I don't see how the entry_INT80_compat entry point could work at all - the software interrupt itself already pushes values on the kernel stack. You could maybe work around that using some sort of trampoline stack, but I don't see anything like that. Am I missing something?
[toc] | [prev] | [standalone]
Page 2 of 2 — ← Prev page 1 [2]
Back to top | Article view | linux.kernel
csiph-web