kernel-hardening - Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

Follow @Openwall on Twitter for new release announcements and other news

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

Message-ID: <CA+55aFw96289kXRz9q7N=d4GD3eJxQB8ddV=GXMYm+Cd6Pk=Bg@mail.gmail.com>
Date: Fri, 24 Jun 2016 14:32:38 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Andy Lutomirski <luto@...capital.net>
Cc: Josh Poimboeuf <jpoimboe@...hat.com>, Brian Gerst <brgerst@...il.com>, 
	Peter Zijlstra <peterz@...radead.org>, Oleg Nesterov <oleg@...hat.com>, 
	Andy Lutomirski <luto@...nel.org>, "the arch/x86 maintainers" <x86@...nel.org>, 
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, 
	"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>, Borislav Petkov <bp@...en8.de>, 
	Nadav Amit <nadav.amit@...il.com>, Kees Cook <keescook@...omium.org>, 
	"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>, Jann Horn <jann@...jh.net>, 
	Heiko Carstens <heiko.carstens@...ibm.com>
Subject: Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core)

On Fri, Jun 24, 2016 at 2:25 PM, Andy Lutomirski <luto@...capital.net> wrote:
>
> What's the prognosis for this patch?  Should I queue up all the pieces
> and send them out after the vmap-stack thing?

I'm going to split this thing up and apply the "semantically null"
cleanup parts.

For example, this patch makes it clear that our current
"alloc_thread_info_node()" this is entirely insane.

We literally do:

        ti = alloc_thread_info_node(tsk, node);
        ...
        tsk->stack = ti;

and

        arch_release_thread_info(tsk->stack);
        free_thread_info(tsk->stack);

and the pure *confusion* there is just crazy. We're talking
"tsk->stack", but then we talk about freeing and allocating
"thread_info"

So I'll apply the whole "rename 'free_thread_info()' into
'free_thread_stack()'" part independently of anything else. It will
not change any semantics at all, since we currently have "tsk->stack
== thread_info", but it's too ugly to live, and it will then make the
patches that *do* change semantics much clearer and easier to see.

So let me get the pure semantic patches done, and then for 4.8 when we
do the things that actually change real meaning we'll have a sane
base. Ok?

                   Linus

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.