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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 16A01C77B6E for ; Wed, 12 Apr 2023 14:51:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To: Subject:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=iyuaZjMX3+SEwjjiMKM5EVvVdZHpM+ynSUxRD/xcais=; b=hOQ6ymBRWsgv0p qEuzlL/YPx4RYvZVXlKziaKN5FNyrQwzUvuP53+EglC74ZQw5z+7C6DgpOvBs1knlQBxbPFeSzhcJ 8rbTIm+KrBuxrGHItfoh/4yi/v3mWMZxTdn9Wetw75vcWvUF0ypAbsGhWBSLaKEw4PEl1Yn8qedRK 9HMBgdZmuv+btsiTCH2hCk5YV+DIGxAKZg6rKpf8n0sA59G8NP+LV8vwS4Dgp2btP0TLhuDlpIpfT JpbPS/wxzyj1MkEuUnk+MCf9AmgiW+qhaPKRe89wnVxflAxUQOSz2WP02K9Q24DoE9mr3aotu+5JH e6UeeNZLcd/vYL7ltONA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pmbns-003XO8-0f; Wed, 12 Apr 2023 14:50:32 +0000 Received: from linux.microsoft.com ([13.77.154.182]) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pmbno-003XLw-23 for linux-arm-kernel@lists.infradead.org; Wed, 12 Apr 2023 14:50:30 +0000 Received: from [192.168.254.32] (unknown [47.189.246.67]) by linux.microsoft.com (Postfix) with ESMTPSA id 9DAC221779BE; Wed, 12 Apr 2023 07:50:24 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 9DAC221779BE DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1681311025; bh=a2g85I/zkHv3WQbT0/vKcSSQ7JahFwxJtyq1yZd7bgc=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=BNkPDiKCL7z3QB+MvMHPzZboIzRe+XN/3O+Gr4IpvKSwjDzp1T84ZfUcv/HvUfNXs izKXgALT10encUMNTX2ikNoB0uJb4Jc1nPtTjEb3foAusUhcKYFgJUtYSwLWQdX1bY icwwW3djsWFqQygVX3X/GL5JPiBK8EjhT4gx8qfA= Message-ID: Date: Wed, 12 Apr 2023 09:50:23 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: [RFC PATCH v3 00/22] arm64: livepatch: Use ORC for dynamic frame pointer validation To: Josh Poimboeuf Cc: Mark Rutland , jpoimboe@redhat.com, peterz@infradead.org, chenzhongjin@huawei.com, broonie@kernel.org, nobuta.keiya@fujitsu.com, sjitindarsingh@gmail.com, catalin.marinas@arm.com, will@kernel.org, jamorris@linux.microsoft.com, linux-arm-kernel@lists.infradead.org, live-patching@vger.kernel.org, linux-kernel@vger.kernel.org References: <0337266cf19f4c98388e3f6d09f590d9de258dc7> <20230202074036.507249-1-madvenka@linux.microsoft.com> <054ce0d6-70f0-b834-d4e5-1049c8df7492@linux.microsoft.com> <20230412041752.i4raswvrnacnjjgy@treble> <20230412050106.7v4s3lalg43i6ciw@treble> Content-Language: en-US From: "Madhavan T. Venkataraman" In-Reply-To: <20230412050106.7v4s3lalg43i6ciw@treble> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230412_075028_732767_DE52D3B3 X-CRM114-Status: GOOD ( 19.27 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 On 4/12/23 00:01, Josh Poimboeuf wrote: > On Tue, Apr 11, 2023 at 11:48:21PM -0500, Madhavan T. Venkataraman wrote: >> >> >> On 4/11/23 23:17, Josh Poimboeuf wrote: >>> On Tue, Apr 11, 2023 at 02:25:11PM +0100, Mark Rutland wrote: >>>>> By your own argument, we cannot rely on the compiler as compiler implementations, >>>>> optimization strategies, etc can change in ways that are incompatible with any >>>>> livepatch implementation. >>>> >>>> That's not quite my argument. >>>> >>>> My argument is that if we assume some set of properties that compiler folk >>>> never agreed to (and were never made aware of), then compiler folk are well >>>> within their rights to change the compiler such that it doesn't provide those >>>> properties, and it's very likely that such expectation will be broken. We've >>>> seen that happen before (e.g. with jump tables). >>>> >>>> Consequently I think we should be working with compiler folk to agree upon some >>>> solution, where compiler folk will actually try to maintain the properties we >>>> depend upon (and e.g. they could have tests for). That sort of co-design has >>>> worked well so far (e.g. with things like kCFI). >>>> >>>> Ideally we'd have people in the same room to have a discussion (e.g. at LPC). >>> >>> That was the goal of my talk at LPC last year: >>> >>> https://lpc.events/event/16/contributions/1392/ >>> >>> We discussed having the compiler annotate the tricky bits of control >>> flow, mainly jump tables and noreturns. It's still on my TODO list to >>> prototype that. >>> >>> Another alternative which has been suggested in the past by Indu and >>> others is for objtool to use DWARF/sframe as an input to help guide it >>> through the tricky bits. >>> >> >> I read through the SFrame spec file briefly. It looks like I can easily adapt my >> version 1 of the livepatch patchset which was based on DWARF to SFrame. If the compiler >> folks agree to properly support and maintain SFrame, then I could send the next version >> of the patchset based on SFrame. >> >> But I kinda need a clear path forward before I implement anything. I request the arm64 >> folks to comment on the above approach. Would it be useful to initiate an email discussion >> with the compiler folks on what they plan to do to support SFrame? Or, should this all >> happen face to face in some forum like LPC? > > SFrame is basically a simplified version of DWARF unwind, using it as an > input to objtool is going to have the same issues I mentioned below (and > as was discussed with your v1). > Yes. It is a much simplified version of DWARF. So, I am hoping that the compiler folks can provide the feature with a reliability guarantee. DWARF is too complex. Madhavan >>> That seems more fragile -- as Madhavan mentioned, GCC-generated DWARF >>> has some reliability issues -- and also defeats some of the benefits of >>> reverse-engineering in the first place (we've found many compiler bugs >>> and other surprising kernel-compiler interactions over the years). >>> >>> Objtool's understanding of the control flow graph has been really >>> valuable for reasons beyond live patching (e.g., noinstr and uaccess >>> validation), it's definitely worth finding a way to make that more >>> sustainable. > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel