Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754551AbcLTVVm (ORCPT ); Tue, 20 Dec 2016 16:21:42 -0500 Received: from mx1.redhat.com ([209.132.183.28]:47912 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753185AbcLTVVj (ORCPT ); Tue, 20 Dec 2016 16:21:39 -0500 Date: Tue, 20 Dec 2016 15:21:36 -0600 From: Josh Poimboeuf To: Petr Mladek Cc: Miroslav Benes , Jessica Yu , Jiri Kosina , linux-kernel@vger.kernel.org, live-patching@vger.kernel.org, Michael Ellerman , Heiko Carstens , x86@kernel.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, Vojtech Pavlik , Jiri Slaby , Chris J Arges , Andy Lutomirski , Ingo Molnar , Peter Zijlstra Subject: Re: [PATCH v3 01/15] stacktrace/x86: add function for detecting reliable stack traces Message-ID: <20161220212136.gdy4zof4qlvi6vhi@treble> References: <0315b36c08c104d56a4b43537fb300d200418996.1481220077.git.jpoimboe@redhat.com> <20161219172549.mjm4c2midvkumqxb@treble> <20161220093916.GA14894@pathway.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20161220093916.GA14894@pathway.suse.cz> User-Agent: Mutt/1.6.0.1 (2016-04-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Tue, 20 Dec 2016 21:21:39 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 974 Lines: 21 On Tue, Dec 20, 2016 at 10:39:16AM +0100, Petr Mladek wrote: > On Mon 2016-12-19 11:25:49, Josh Poimboeuf wrote: > > 3) probably some kind of runtime NMI stack checking feature to > > complement objtool, along with a lot of burn time to ensure there are > > no issues, particularly in entry code > > Could you please provide more details about this NMI stack checking? > What is it supposed to protect that objtool could not? > Will it run regularly or will it be just a random check? save_stack_trace_tsk_reliable(current) would be called periodically from an NMI handler, and a warning would be printed if it ever doesn't reach the "end" of the stack (i.e., user-mode pt_regs). Due to the performance impact it would probably only be a debug option. It would verify the special hand-coded areas which objtool isn't smart enough to understand, like entry code, ftrace, kprobes, bpf. It would also make sure that objtool itself didn't missing anything. -- Josh