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]

Message-ID: <db80ae9d-15bc-5d32-afce-ea98a6059fb8@iaik.tugraz.at>
Date:   Mon, 8 May 2017 12:51:27 +0200
From:   Daniel Gruss <daniel.gruss@...k.tugraz.at>
To:     Mark Rutland <mark.rutland@....com>
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

> 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.