[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150610142021.GC25848@treble.redhat.com>
Date: Wed, 10 Jun 2015 09:20:21 -0500
From: Josh Poimboeuf <jpoimboe@...hat.com>
To: Pavel Machek <pavel@....cz>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>, 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>, x86@...nel.org,
live-patching@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 00/10] x86/asm: Compile-time asm code validation
On Wed, Jun 10, 2015 at 03:42:41PM +0200, Pavel Machek wrote:
> On Wed 2015-06-10 07:06:08, Josh Poimboeuf wrote:
> > The previous version of this patch set was named "Compile-time stack
> > frame pointer validation". I changed the subject from "frame pointer
> > validation" to "asm code validation" because the focus of the patch set
> > has changed to be less frame pointer-focused and more asm-focused. I
> > also renamed the tool to asmvalidate (it was previously called
> > stackvalidate) and basically rewrote most of the code.
> >
> > The goal of asm validation is to enforce sane rules on asm code: all
> > callable asm functions must be self-contained and properly annotated.
> >
> > Some of the benefits are:
> >
> > - Frame pointers are more reliable.
> >
> > - DWARF CFI metadata can be autogenerated (coming soon).
> >
> > - The asm code becomes less like spaghetti, more like C, and easier to
> > comprehend.
> >
> >
> > The asmvalidate tool runs on every compiled .S file, and enforces the
> > following rules:
> >
> > 1. Each callable function must be annotated with the ELF STT_FUNC type.
> > This is typically done using the existing ENTRY/ENDPROC macros. If
> > asmvalidate finds a return instruction outside of a function, it
> > flags an error, since that usually indicates callable code which
> > should be annotated accordingly.
> >
> > 2. Each callable function must never leave its own bounds (i.e. with a
> > jump to outside the function) except when returning.
> >
> > 3. Each callable non-leaf function must have frame pointer logic (if
> > required by CONFIG_FRAME_POINTER or the architecture's back chain
> > rules). This should by done by the FP_SAVE/FP_RESTORE macros.
> >
> >
> > It currently only supports x86_64, but the code is generic and designed
> > for it to be easy to plug in support for other architectures.
> >
> > There are still a lot of outstanding warnings (which I'll paste as a
> > reply to this email). Once those are all cleaned up, we can change the
> > warnings to build errors and change the default to
> > CONFIG_ASM_VALIDATION=y so the asm code stays clean.
>
> You have interesting definition of "clean".
"clean":
- reliably honors CONFIG_FRAME_POINTER
- reliably creates/generates DWARF CFI metadata
- doesn't break stack walking
- code is more readable
> The reason we sometimes have to use assembly is that it is impossible
> to write corresponding code in C, or that performance would be bad.
Agreed, but I don't see how this patch set prevents those things.
> So... fixing these may have some sense, but I doubt enforcing "you
> can't write real assembly" is a good idea.
You can certainly still write real assembly. This just creates a few
constraints. I really don't think they are very limiting.
--
Josh
--
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/
Powered by blists - more mailing lists