linux-kernel - Re: [PATCH v11 03/20] x86/stackvalidate: Compile-time stack validation

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: <20150826142628.GN1747@two.firstfloor.org>
Date:	Wed, 26 Aug 2015 16:26:28 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Josh Poimboeuf <jpoimboe@...hat.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
	linux-kernel@...r.kernel.org, live-patching@...r.kernel.org,
	Michal Marek <mmarek@...e.cz>,
	Peter Zijlstra <peterz@...radead.org>,
	Andy Lutomirski <luto@...nel.org>,
	Borislav Petkov <bp@...en8.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andi Kleen <andi@...stfloor.org>,
	Pedro Alves <palves@...hat.com>,
	Namhyung Kim <namhyung@...il.com>,
	Bernd Petrovitsch <bernd@...rovitsch.priv.at>,
	Chris J Arges <chris.j.arges@...onical.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH v11 03/20] x86/stackvalidate: Compile-time stack
 validation

> b) 100% reliable stack traces for DWARF enabled kernels
> 
>    This is not yet implemented.  See Documentation/stack-validation.txt
>    for more details about what is planned.

The automatic CFI generation tool seems like a bad idea to me. There's not
that much assembler code in Linux, and often when new assembler code is added
it is something tricky. In this case you may end up spending more time
fixing the tool than just fixing the assembler.

It would be also quite bad to require people who want to add some
new assembler code to learn how to fix your tool to make their
assembler work.

It also wouldn't surprise me if there are some possible assembler tricks
that are very hard/impossible to handle for a tool. For example how do you 
have alternative() style patching? (that's a generic problem with
your approach BTW)

Doing some kind of CFI verifier would seem more feasible,  but it would
need a black/white list to override it to handle the above cases.

BTW how do handle the increasing number of JITs in the kernel?

-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/