Date: Wed, 10 Jun 2015 09:20:21 -0500
From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>,
        "H. Peter Anvin" <hpa@zytor.com>, Michal Marek <mmarek@suse.cz>,
        Peter Zijlstra <peterz@infradead.org>,
        Andy Lutomirski <luto@kernel.org>, Borislav Petkov <bp@alien8.de>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Andi Kleen <andi@firstfloor.org>, x86@kernel.org,
        live-patching@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 00/10] x86/asm: Compile-time asm code validation
Message-ID: <20150610142021.GC25848@treble.redhat.com>
References: <cover.1433937132.git.jpoimboe@redhat.com>
 <20150610134241.GA2993@amd>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20150610134241.GA2993@amd>
User-Agent: Mutt/1.5.23.1-rc1 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3069
Lines: 75

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/