From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752027AbcALTh1 (ORCPT ); Tue, 12 Jan 2016 14:37:27 -0500 Received: from mail.skyhub.de ([78.46.96.112]:56110 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751568AbcALThY (ORCPT ); Tue, 12 Jan 2016 14:37:24 -0500 Date: Tue, 12 Jan 2016 20:37:10 +0100 From: Borislav Petkov To: Josh Poimboeuf Cc: Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, linux-kernel@vger.kernel.org, live-patching@vger.kernel.org, Michal Marek , Peter Zijlstra , Andy Lutomirski , Linus Torvalds , Andi Kleen , Pedro Alves , Namhyung Kim , Bernd Petrovitsch , Chris J Arges , Andrew Morton , Jiri Slaby , Arnaldo Carvalho de Melo Subject: Re: [PATCH v15 13/25] x86/reboot: Add ljmp instructions to stacktool whitelist Message-ID: <20160112193710.GM30558@pd.tnic> References: <20160112164711.GD22699@pd.tnic> <20160112174301.GD310@treble.redhat.com> <20160112175540.GI30558@pd.tnic> <20160112185606.GF310@treble.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160112185606.GF310@treble.redhat.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 12, 2016 at 12:56:06PM -0600, Josh Poimboeuf wrote: > I'd say those are all weird things that C code should _normally_ not do > (especially emitting fake instructions!). The kernel does weird things, that's fine. > Generally I agree (but I don't know what other tools you're talking > about which require adding clutter). kasan and kmemleak, for example. > As I said there's hopefully only a handful of code locations which > need the STACKTOOL_IGNORE stuff. Can you get rid of them too? > For example, how can it possibly grok a fake xen instruction without > some kind of a whitelist, either hard-coded in the tool or annotated > some other way? I'd much prefer a whitelist which the tool parses, loads, etc, if you don't want to hardcode it, to annotating kernel code. > For example, how can it possibly grok a fake xen instruction without > some kind of a whitelist, either hard-coded in the tool or annotated > some other way? Pointer to the place? I could take a look when I get a chance. > Saying nothing at all in order to prevent false positives would also > by definition allow some false negatives, which would make stacktool > useless for its intended purpose of enabling reliable stack traces. I'd take output from the tool anyday of the week which says something like: "Looka here, this looks funny, you might want to do something about it." than imposing annotations on code. It might even move people into rewriting the code into tool-compliant version. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply.