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

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:	Fri, 24 Jun 2016 14:34:59 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
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:32 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> 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?
>

Works for me.  I'll see whether my vmap patches still apply and, if
needed, rebase and send a v5.

--Andy