linux-kernel - Re: [PATCH 0/3] ABI CHANGE!!! Remove questionable remote SP reads

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: <1475564818.7361.12@smtp.gmail.com>
Date:   Tue, 04 Oct 2016 00:06:58 -0700
From:   Raymond Jennings <shentino@...il.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Andy Lutomirski <luto@...capital.net>,
        Andy Lutomirski <luto@...nel.org>, X86 ML <x86@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Brian Gerst <brgerst@...il.com>,
        Borislav Petkov <bp@...en8.de>, Jann Horn <jann@...jh.net>,
        Linux API <linux-api@...r.kernel.org>,
        Kees Cook <keescook@...omium.org>,
        Tycho Andersen <tycho.andersen@...onical.com>
Subject: Re: [PATCH 0/3] ABI CHANGE!!! Remove questionable remote SP reads

My personal opinion is that even looking at esp/rsp is asking for 
trouble.  The only reliable information is VM_STACK or another VM flag 
that makes the area expand in response to stack growth.

Besides, userspace could always play funky trampoline games with the 
stack pointer, or even dynamically expand the stack by doing a malloc 
if a stack overflow draws near, which would put the stack in the data 
section temporarily.

As long as esp is in the bounds of a valid VMA, my vote is that we 
should consider it undefined how the task uses it.

On Mon, Oct 3, 2016 at 4:17 PM, Linus Torvalds 
<torvalds@...ux-foundation.org> wrote:
> On Mon, Oct 3, 2016 at 4:08 PM, Andy Lutomirski <luto@...capital.net> 
> wrote:
>> 
>>  Ping!
>> 
>>  We need to decide fairly soon whether to apply these (or perhaps 
>> just
>>  patch 1 or just patches 2 and 3) for 4.9.  For any parts that aren't
>>  applied, I'll send quick fixups to pin the stack in the offending
>>  code.
> 
> I think we should apply it. Hopefully nothing uses it, and nobody will
> notice. And if somebody *does* notice, the sooner we find out, the
> better.
> 
>              Linus