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 10:56:00 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	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>,
	Josh Poimboeuf <jpoimboe@...hat.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 10:47 AM, Andy Lutomirski <luto@...capital.net> wrote:
>
> FWIW, your patch is much more lenient than my approach.

I hate big flag-days - they cause so much pain for everybody. The
people who get it to work and can test it, can't test all the other
cases (whether they be drivers or other architectures), so I'd much
rather implement something that allows a gradual per-architecture
change from having the thread_info on the stack into having the
thread_info in the task_struct.

Bit "let's just change everything at once" patches are fine (and, in
fact, preferable) when you can test everything in one go. So something
that can be statically verified (ie "patch makes no semantic
difference, but changes calling convention or naming, so if it
compiles it is fine") I much prefer just getting the pain over and
done with rather than some lingering thing.

But when it's something where "oops, I broke every other architecture,
and I can't even test it", I'd much rather do it in a way where each
architecture can move over to the new model one by one.

                  Linus