linux-kernel - Re: [PATCH v15 13/25] x86/reboot: Add ljmp instructions to stacktool whitelist

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:	Tue, 12 Jan 2016 18:55:40 +0100
From:	Borislav Petkov <bp@...en8.de>
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>,
	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>,
	Jiri Slaby <jslaby@...e.cz>,
	Arnaldo Carvalho de Melo <acme@...nel.org>
Subject: Re: [PATCH v15 13/25] x86/reboot: Add ljmp instructions to stacktool
 whitelist

On Tue, Jan 12, 2016 at 11:43:01AM -0600, Josh Poimboeuf wrote:
> Well, these STACKTOOL_IGNORE whitelist markers are only needed in a
> handful of places, and only for code that does very weird things.  Yes,
> they're a bit ugly, but IMO they also communicate valuable information:
> "be careful, this code does something very weird."

Weird for whom?

> As for whether to put the whitelist info in the code vs hard-coding it
> in stacktool, I think it's clearer and less "magical" to put them
> directly in the code.

I don't think so. All that unnecessary clutter just gets in the way
of actually writing code. Sure, those tools are all good and nice but
again, they should *not* have to touch the code. We want people to
concentrate on writing code, not paying attention to gazillion tools
breaking from their changes.

> It's also more resilient to future code changes, e.g. if the offending
> instruction gets moved or if the function gets renamed.

So make your tool parse vmlinux properly.

> And it gives you the ability to more granularly whitelist instructions
> rather than entire functions, which could cause other offending stack
> violations in the function to get overlooked.

No no no, the moment you have to *whitelist* something is already wrong.
Normal kernel code shouldn't have to whitelist anything - the tools
should strive to be smart, instead.

> Another thing is that stacktool could be a nice general purpose tool for
> finding stack issues in other code bases, and so I think requiring it to
> have hard-coded knowledge about the code base would greatly limit its
> general usefulness.  (Though maybe this problem could be remediated with
> a user-provided whitelist file which lists functions to be ignored.)

I can use the same argument for me: all those other code bases would
need annotating too.

Again, the onus should always be on the tool to do the right thing.
If it cannot, it should not say anything.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.