[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160112150639.GC310@treble.redhat.com>
Date: Tue, 12 Jan 2016 09:06:39 -0600
From: Josh Poimboeuf <jpoimboe@...hat.com>
To: Borislav Petkov <bp@...en8.de>
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 06/25] x86/stacktool: Compile-time stack metadata
validation
On Tue, Jan 12, 2016 at 03:48:29PM +0100, Borislav Petkov wrote:
> On Fri, Dec 18, 2015 at 06:39:20AM -0600, Josh Poimboeuf wrote:
> > This adds a CONFIG_STACK_VALIDATION option which enables a host tool
> > named stacktool which runs at compile time. It analyzes every .o file
> > and ensures the validity of its stack metadata. It enforces a set of
> > rules on asm code and C inline assembly code so that stack traces can be
> > reliable.
> >
> > For each function, it recursively follows all possible code paths and
> > validates the correct frame pointer state at each instruction.
> >
> > It also follows code paths involving special sections, like
> > .altinstructions, __jump_table, and __ex_table, which can add
> > alternative execution paths to a given instruction (or set of
> > instructions). Similarly, it knows how to follow switch statements, for
> > which gcc sometimes uses jump tables.
>
> Have you run this through checkpatch?
>
> Some of the warnings make sense, like:
>
> ERROR: Do not include the paragraph about writing to the Free Software Foundation's mailing address from the sample GPL notice. The FSF has changed addresses in the past, and may do so again. Linux already includes a copy of the GPL.
> #2496: FILE: tools/stacktool/arch/x86/insn/insn.h:17:
> + * along with this program; if not, write to the Free Software$
This file is a straight copy from the kernel arch/x86/include/asm/insn.h
file, and there's even a Makefile target which warns if there are any
differences between the two. I figured it's such a minor issue that it
wasn't worth the churn to fix both files.
There are several other warnings from the copied files (insn.h and
list.h) but again I figured it wasn't worth the churn to fix them all.
I did run checkpatch on previous revisions of the patch set, though I
admit I forgot to run it on this one, and so I missed the improperly
formatted commit id reference in the list.h copy commit which you
pointed out.
Otherwise, all the remaining warnings seemed bogus to me.
--
Josh
Powered by blists - more mailing lists