Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1637373
| From | Daniel Gruss <daniel.gruss@iaik.tugraz.at> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [kernel-hardening] [RFC, PATCH] x86_64: KAISER - do not map kernel in user mode |
| Date | 2017-05-08 13:00 +0200 |
| Message-ID | <tEOyt-2Rv-13@gated-at.bofh.it> (permalink) |
| References | (2 earlier) <tDGMF-7Ep-9@gated-at.bofh.it> <tDNEt-3DR-7@gated-at.bofh.it> <tDZFD-3kp-1@gated-at.bofh.it> <tE3pU-5Jf-5@gated-at.bofh.it> <tEO5s-2HR-7@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
> 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.
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