From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1756685AbbHZO0c (ORCPT <rfc822;w@1wt.eu>);
	Wed, 26 Aug 2015 10:26:32 -0400
Received: from one.firstfloor.org ([193.170.194.197]:45662 "EHLO
	one.firstfloor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1752648AbbHZO0a (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 26 Aug 2015 10:26:30 -0400
Date: Wed, 26 Aug 2015 16:26:28 +0200
From: Andi Kleen <andi@firstfloor.org>
To: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>,
        "H. Peter Anvin" <hpa@zytor.com>, x86@kernel.org,
        linux-kernel@vger.kernel.org, live-patching@vger.kernel.org,
        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>, Pedro Alves <palves@redhat.com>,
        Namhyung Kim <namhyung@gmail.com>,
        Bernd Petrovitsch <bernd@petrovitsch.priv.at>,
        Chris J Arges <chris.j.arges@canonical.com>,
        Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH v11 03/20] x86/stackvalidate: Compile-time stack
 validation
Message-ID: <20150826142628.GN1747@two.firstfloor.org>
References: <cover.1440423732.git.jpoimboe@redhat.com>
 <b51f16a2756f4daaf8c146461384b0726757afb9.1440423732.git.jpoimboe@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <b51f16a2756f4daaf8c146461384b0726757afb9.1440423732.git.jpoimboe@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> b) 100% reliable stack traces for DWARF enabled kernels
> 
>    This is not yet implemented.  See Documentation/stack-validation.txt
>    for more details about what is planned.

The automatic CFI generation tool seems like a bad idea to me. There's not
that much assembler code in Linux, and often when new assembler code is added
it is something tricky. In this case you may end up spending more time
fixing the tool than just fixing the assembler.

It would be also quite bad to require people who want to add some
new assembler code to learn how to fix your tool to make their
assembler work.

It also wouldn't surprise me if there are some possible assembler tricks
that are very hard/impossible to handle for a tool. For example how do you 
have alternative() style patching? (that's a generic problem with
your approach BTW)

Doing some kind of CFI verifier would seem more feasible,  but it would
need a black/white list to override it to handle the above cases.

BTW how do handle the increasing number of JITs in the kernel?

-Andi