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 14:22:35 +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

On Mon, May 08, 2017 at 12:51:27PM +0200, Daniel Gruss wrote:
> >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.

Sure; if we consider Linux, while userspace is executing, TTBR1 will
(only) contain kernel page tables and TTBR0 will (only) contain user
page tables.

However, as this is not an architectural requirement, the CPU cannot
know that a user access that gets translated via TTBR1 will fault, and
at some point must determine the permissions from the page tables as
required by the architecture.

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

In practice, while userspace is executing, TTBR1 still points to kernel
page tables. If a user program attempts to access an address mapped via
TTBR1, the CPU has to attempt this translation via the TTBR1 page tables
and/or associated TLB entries.

Specifically, I think this does not align with the statement in 2.1
regarding the two TTBRs:

  This simplifies privilege checks and does not require any address
  translation for invalid memory accesses and thus no cache lookups.

... since the use of the TTBRs is orthogonal to privilege checks and/or
the design of the TLBs.

Thanks,
Mark.