linux-kernel - Re: [PATCH v2 1/3] x86/entry: Clear extra registers beyond syscall arguments for 64bit kernels

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] [day] [month] [year] [list]

Message-ID: <20180206071933.3rbyglzndtsxcu47@gmail.com>
Date:   Tue, 6 Feb 2018 08:19:33 +0100
From:   Ingo Molnar <mingo@...nel.org>
To:     Andi Kleen <ak@...ux.intel.com>
Cc:     Dan Williams <dan.j.williams@...el.com>, tglx@...utronix.de,
        x86@...nel.org, linux-kernel@...r.kernel.org,
        Ingo Molnar <mingo@...hat.com>, luto@...nel.org,
        "H. Peter Anvin" <hpa@...or.com>, torvalds@...ux-foundation.org
Subject: Re: [PATCH v2 1/3] x86/entry: Clear extra registers beyond syscall
 arguments for 64bit kernels


* Andi Kleen <ak@...ux.intel.com> wrote:

> >      - There's various conditional pieces of entry code that run before any 
> >        RBP-clobbering C function is called. While none of them has an exploitable 
> >        Spectre 'gadget' at the moment, we'd have to consider this for every future
> >        change.
> 
> The Frame Pointer is always set up in assembler too, just in another macro.

As I replied to Andy, that's not universally true: there are code paths where RBP 
is not set before calling C code or going into the more complex parts of the 
kernel entry code.

This RBP value leak in fact demonstrates the validity of my robustness argument:

> >   I.e. we cannot universally rely on RBP being sanitized. In _practice_ it 
> >   will be sanitized, but we don't know for sure without expending quite some 
> >   effort to think through all the cases.

Thanks,

	Ingo