Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1636823
| From | David Gens <david.gens@cs.tu-darmstadt.de> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [kernel-hardening] [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode |
| Date | 2017-05-06 06:40 +0200 |
| Message-ID | <tDZFD-3kp-1@gated-at.bofh.it> (permalink) |
| References | <tDm1z-24V-7@gated-at.bofh.it> <tDqRA-5hr-17@gated-at.bofh.it> <tDGMF-7Ep-9@gated-at.bofh.it> <tDNEt-3DR-7@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll 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