From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 40E7DC433E6 for ; Thu, 28 Jan 2021 15:28:09 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D0B7D64DFA for ; Thu, 28 Jan 2021 15:28:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D0B7D64DFA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=sJhFDC/CheV8txW91+/RUnk1Z+24v+jQknkZ2dZOiPc=; b=j5IxR06N213/SssDXjxwBJ9MN iJP4p8vvyzgRrukvSFp0hShSAEGooysRfuI6zVjaYgLkJB3Qu6TDOekgMDv02xO5c5EiGPGzR7JV9 5+gmQ03Gi1LypihUog2zkRUTOgCKhKrTvV8gXfwTp2JK3GGKx8hVhAScdFfcAQGD+cLxvY6HmTE0d xRCNqJt/8xFwHMqJFOkKNe7B4vV8UaYikwQgZNrodSUxFi9JO9k1t9hpSokFMvlW44csXI0yTIFsj 0Y/9Lk5HskEYKd9FnbiFiVKGIqwZGwR4+cqrHMyPiH6Yel6N2xwPd4wpb9IWYJ1DUWEPu8JAKw2ML 2NTD9xpdQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l59CH-0007LF-Fm; Thu, 28 Jan 2021 15:27:01 +0000 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1l59CF-0007KY-Et for linux-arm-kernel@lists.infradead.org; Thu, 28 Jan 2021 15:27:00 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1611847617; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=PEngXJAfeP4Ks4kADW0Ih5vhrgd3MAQvXAM7zpbqZpE=; b=P6LSKHONbxkeSs4JT6mjQWLWFlVTqCgG9dLNFnYI/IwOASdv1naEtNwbNyWUM/oCmVharC WmT/QxI/jI0G696+GDoaq+s79ZAepnHn5tOPdE+sjNFvje02A72IucmOhMX/T1iAttiPVo HE+em0NMrlBm/78XwhPNyDOTNF8XCaU= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-243-MsqjaEEzPpywinqyo7AQyw-1; Thu, 28 Jan 2021 10:26:53 -0500 X-MC-Unique: MsqjaEEzPpywinqyo7AQyw-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 5DEB5107ACE4; Thu, 28 Jan 2021 15:26:52 +0000 (UTC) Received: from treble (ovpn-120-118.rdu2.redhat.com [10.10.120.118]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 77D241A7C1; Thu, 28 Jan 2021 15:26:51 +0000 (UTC) Date: Thu, 28 Jan 2021 09:26:49 -0600 From: Josh Poimboeuf To: Mark Brown Subject: Re: [RFC PATCH 0/3] arm64: Implement reliable stack trace Message-ID: <20210128152649.6zin3hzim3etbv2p@treble> References: <20201012172605.10715-1-broonie@kernel.org> <13095563-ff6d-b806-1bf3-efde4383456e@linux.microsoft.com> <20210128142250.GC4537@sirena.org.uk> MIME-Version: 1.0 In-Reply-To: <20210128142250.GC4537@sirena.org.uk> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=jpoimboe@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210128_102659_562360_51480AE7 X-CRM114-Status: GOOD ( 36.54 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Julien Thierry , Catalin Marinas , "Madhavan T. Venkataraman" , Miroslav Benes , Will Deacon , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi all, I know this is an old patch set, but I'm not able to see the context, because I'm not subcribed to the ML. For future patch sets can you also add live-patching and lkml? Are we still considering the shadow stack thing? Just wondering why we're talking about objtool again. On Thu, Jan 28, 2021 at 02:22:50PM +0000, Mark Brown wrote: > On Wed, Jan 27, 2021 at 01:54:21PM -0600, Madhavan T. Venkataraman wrote: > > Instead of failing the kernel build, can we just mark the functions as: > > > FP Functions that have proper FP code > > no-FP Functions that don't > > > May be, we can add an "FP" flag in the symbol table entry for this. > > > Then, the unwinder can check the functions it encounters in the stack trace and > > inform the caller if it found any no-FP functions. The caller of the unwinder can > > decide what he wants to do with that information. > > > > - the caller can ignore it > > > > - the caller can print the stack trace with a warning that no-FP functions > > were found > > > > - if the caller is livepatch, the caller can retry until the no-FP functions > > disappear from the stack trace. This way, we can have live patching even > > when some of the functions in the kernel are no-FP. > > > > Does this make any sense? Is this acceptable? What are the pitfalls? Why not just fix the reported no-FP functions? > > If we can do this, the unwinder could detect cases such as: > > > - If gcc thinks that a function is a leaf function but the function contains > > inline assembly code that calls another function. > > > - If a call to a function bounces through some intermediate code such as a > > trampoline. > > > - etc. > > > For specific no-FP functions, the unwinder might be able to deduce the original > > caller. In these cases, the stack trace would still be reliable. For all the others, > > the stack trace would be considered unreliable. > > I'm not entirely sure I see the distinction from the current situation > here? > > > Compiler instead of objtool > > =========================== > > > > If the above suggestion is acceptable, I have another suggestion. > > > > It is a lot of work for every new architecture to add frame pointer verification > > support in objtool. Can we get some help from the compiler? > > > > The compiler knows which C functions it generates the FP prolog and epilog for. It can > > mark those functions as FP. As for assembly functions, kernel developers could manually > > annotate functions that have proper FP code. The compiler/assembler would mark them > > as FP. Only a small subset of assembly functions would even have FP prolog and epilog. > > > Is this acceptable? What are the pitfalls? > > If we're trusting the compiler we can probably just do that without any > explicit support from the compiler - it should be doing the standard > stuff unless we explicitly ask it to and if it isn't then it might be a > result of a mismatch in assumptions rather than a deliberate decision to > do something non-standard. My understanding with objtool is that a big > part of the idea is to provide a static check that the binary we end up > with matches the assumptions that we are making so the fact that it's a > separate implementation is important. For C code, even if we trusted the compiler (which we don't), we still have inline asm which the compiler doesn't have any visibility to, which is more than capable of messing up frame pointers (we had several cases of this in x86). Getting the assembler to annotate which functions are FP could be interesting but: a) good luck getting the assembler folks to do that; they tend to be insistent on being ignorant of code semantics; b) assembly often resembles spaghetti and the concept of a function is quite fluid; in fact many functions aren't annotated as such. -- Josh _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel