From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752683AbdEHNPA (ORCPT ); Mon, 8 May 2017 09:15:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59642 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750925AbdEHNO7 (ORCPT ); Mon, 8 May 2017 09:14:59 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 8CF8F83F47 Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jpoimboe@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 8CF8F83F47 Date: Mon, 8 May 2017 08:14:56 -0500 From: Josh Poimboeuf To: Vojtech Pavlik Cc: hpa@zytor.com, Ingo Molnar , Linus Torvalds , Jiri Slaby , Andrew Morton , live-patching@vger.kernel.org, Linux Kernel Mailing List , Thomas Gleixner , Ingo Molnar , the arch/x86 maintainers , Andy Lutomirski , Jiri Kosina Subject: Re: [PATCH 7/7] DWARF: add the config option Message-ID: <20170508131456.ssh5a5ilhod4kja6@treble> References: <20170505122200.31436-1-jslaby@suse.cz> <20170505122200.31436-7-jslaby@suse.cz> <20170507165524.cdxfuwbd5alr7v6k@treble> <20170507175915.ggwfusgvbwfqsvtz@gmail.com> <3980F538-919F-4A51-B7FE-4EC6E86AA259@zytor.com> <20170507214836.62odebycv42fzngm@treble> <20170508075054.GA24008@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20170508075054.GA24008@suse.com> 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.27]); Mon, 08 May 2017 13:14:58 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 08, 2017 at 09:50:54AM +0200, Vojtech Pavlik wrote: > On Sun, May 07, 2017 at 04:48:36PM -0500, Josh Poimboeuf wrote: > > > > Can objtool verify the unwinder at each address in the kernel, or is that an AI-complete problem? > > > > It can't verify the *unwinder*, but it can verify the data which is fed > > to the unwinder (either DWARF or the structs I proposed above). For > > each function, it follows every possible code path, and it can keep > > track of the stack pointer while doing so. > > In that case, the kernel build process can verify the DWARF data and its > compatibility with the kernel unwinder by running the unwinder against > each kernel code address verifying the output If I understand the idea correctly, we'd have to make the unwinder dual-purpose such that it can run both in the kernel and in some kind of user space objtool test harness. The stack wouldn't be real, so presumably each iteration of the test would only unwind a frame associated with the current function. It wouldn't be able to test edge cases like entry code and generated code which aren't normal "functions", which objtool currently has no way of understanding. Also it wouldn't test how the unwinder deals with corrupt DWARF data or corrupt stacks, unless we integrated some kind of fuzzer in the harness. And, at the end of the day, we'd still just be testing in an artificial unit test environment. So I'm not really crazy about the idea. > and bail if there is a bug in the toolchain that affects it. Objtool can already find _toolchain_ bugs without having to run the unwinder in some kind of emulator. It can't find _unwinder_ bugs, but I really think such testing should be done at runtime in the unwinder's native kernel environment. -- Josh