linux-kernel - Re: [PATCH v5 00/10] x86/asm: Compile-time asm code 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: <20150610134241.GA2993@amd>
Date:	Wed, 10 Jun 2015 15:42:41 +0200
From:	Pavel Machek <pavel@....cz>
To:	Josh Poimboeuf <jpoimboe@...hat.com>
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 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".

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.

So... fixing these may have some sense, but I doubt enforcing "you
can't write real assembly" is a good idea.
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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/