From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752605AbbETKdq (ORCPT ); Wed, 20 May 2015 06:33:46 -0400 Received: from mail-wi0-f175.google.com ([209.85.212.175]:34283 "EHLO mail-wi0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751182AbbETKdo (ORCPT ); Wed, 20 May 2015 06:33:44 -0400 Date: Wed, 20 May 2015 12:33:39 +0200 From: Ingo Molnar To: Josh Poimboeuf Cc: Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Michal Marek , Peter Zijlstra , x86@kernel.org, live-patching@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 0/3] Compile-time stack frame pointer validation Message-ID: <20150520103339.GA22205@gmail.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Josh Poimboeuf wrote: > In discussions around the live kernel patching consistency model RFC > [1], Peter and Ingo correctly pointed out that stack traces aren't > reliable. And as Ingo said, there's no "strong force" which ensures we > can rely on them. > > So I've been thinking about how to fix that. My goal is to eventually > make stack traces reliable. Or at the very least, to be able to detect > at runtime when a given stack trace *might* be unreliable. But improved > stack traces would broadly benefit the entire kernel, regardless of the > outcome of the live kernel patching consistency model discussions. > > This patch set is just the first in a series of proposed stack trace > reliability improvements. Future proposals will include runtime stack > reliability checking, as well as compile-time and runtime DWARF > validations. > > As far as I can tell, there are two main obstacles which prevent frame > pointer based stack traces from being reliable: > > 1) Missing frame pointer logic: currently, most assembly functions don't > set up the frame pointer. Could you please paste here the output of what the new checks print for x86/64 defconfig? > As a first step, all reported non-compliances result in warnings. > Right now I'm seeing 200+ warnings. Once we get them all cleaned > up, we can change the warnings to build errors so the asm code can > stay clean. That's quite a bit ... Thanks, Ingo