linux-kernel - Re: [kernel-hardening] [RFC, PATCH] x86_64: KAISER

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 8 May 2017 11:21:01 +0100
From:   Mark Rutland <mark.rutland@....com>
To:     Daniel Gruss <daniel.gruss@...k.tugraz.at>
Cc:     David Gens <david.gens@...tu-darmstadt.de>,
        Thomas Garnier <thgarnie@...gle.com>,
        kernel list <linux-kernel@...r.kernel.org>,
        Kernel Hardening <kernel-hardening@...ts.openwall.com>,
        clementine.maurice@...k.tugraz.at, moritz.lipp@...k.tugraz.at,
        Michael Schwarz <michael.schwarz@...k.tugraz.at>,
        Richard Fellner <richard.fellner@...dent.tugraz.at>,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        Ingo Molnar <mingo@...nel.org>, anders.fogh@...ta-adan.de
Subject: 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.