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.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,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 31AECC433DB for ; Thu, 21 Jan 2021 11:10:34 +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 C7AF023602 for ; Thu, 21 Jan 2021 11:10:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C7AF023602 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=hzzeYsZDIuZnskvWfmlyuCSMsh7HDVEne9l1k62PYPA=; b=XzNlRS+F02AkwzQ89nrRMfYvG vH9vbeW47H4iSTnfDB8//MkkUuusibSk+47Kd+tV1COhOH+lkgqJKr5biOquggh80NVr63yvlrXFh FCGT9FVIw3dh6KHx6Ri61ivuNLihdJ/Pli1DvroHRAGdlfGAD8lgaXcXHNZ98J+WEHh41VFSk5737 ipQvFqx9MCN+D7oXi2msLeMyxJ3JQPCQ4aNAWAO9j7/Mtp4M7OpPnz6Tnkor2vdfdUOf5WsqQyneG 8NhLL770w0qX/mXg+kMwvyqoKzptx/NX2pKm77hQkJhZKvliRvMZWISQ54zRL9XwXn3PmwSuEV4Rb QZd6XH5Lw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l2XpP-0003ol-D3; Thu, 21 Jan 2021 11:08:39 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1l2XpM-0003nv-RF for linux-arm-kernel@lists.infradead.org; Thu, 21 Jan 2021 11:08:38 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 94C89238D7 for ; Thu, 21 Jan 2021 11:08:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1611227315; bh=YQUmONjuFJfQO3+w3c69Q/thFfuiexPRidAAdRiu/4I=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=eXsK4ulUYoxTk2pQDYKWUxkjrwfPKGUU+526ZmV12ldwenmvaBFJm9xAf7vl4HmiN mFHBBRKQp3StANweprRkvkcZCxpsEgmJevxTsqvsc/u/HRSHcnoOfQ8RNyceGtc2Ip hZmSUbNggiykJW5f6E8dyfluFZrTG4wt6wie0rgunTXkTfusziwCc72mPRlX9ZcFRf 7EOdVIY9O0IO4pLA1hPmT1/0sA99AypH9VMTq5xlsQX9yfj2467cjGdnd4xyKE9bpU k1ABQFVHib30JVqtkfEakqEBnp5ye9s4atmS6/BJiXDOExGDuYsojPVhQRhgGiLR/m bhwVZi02T/tug== Received: by mail-ot1-f43.google.com with SMTP id 63so1239184oty.0 for ; Thu, 21 Jan 2021 03:08:35 -0800 (PST) X-Gm-Message-State: AOAM533osKLh6wfub55n19AeV+6Eat11xbtQND94ClHOkW0B/6ts5seU nA9a6nrqeBF82v9q5pLERDdaN+7DKx99yT86kGo= X-Google-Smtp-Source: ABdhPJwo2sFPs6RxXt98HDUEvN5NXptXToyY/QAZPOw9C1WUrfbLg/W7/BItjqYOvcV42L8f95DMK9wF2/uOi/M9Z1U= X-Received: by 2002:a05:6830:1614:: with SMTP id g20mr4176607otr.77.1611227314720; Thu, 21 Jan 2021 03:08:34 -0800 (PST) MIME-Version: 1.0 References: <20210120173800.1660730-1-jthierry@redhat.com> <186bb660-6e70-6bbf-4e96-1894799c79ce@redhat.com> In-Reply-To: <186bb660-6e70-6bbf-4e96-1894799c79ce@redhat.com> From: Ard Biesheuvel Date: Thu, 21 Jan 2021 12:08:23 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH 00/17] objtool: add base support for arm64 To: Julien Thierry X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210121_060837_056055_102775E4 X-CRM114-Status: GOOD ( 40.47 ) 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 , linux-efi , Michal Marek , Kees Cook , Peter Zijlstra , Catalin Marinas , Masahiro Yamada , Linux Kernel Mailing List , Mark Brown , linux-hardening@vger.kernel.org, Josh Poimboeuf , Will Deacon , Linux ARM 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 Thu, 21 Jan 2021 at 11:26, Julien Thierry wrote: > > Hi Ard, > > On 1/21/21 10:03 AM, Ard Biesheuvel wrote: > > Hello Julien, > > > > On Wed, 20 Jan 2021 at 18:38, Julien Thierry wrote: > >> > >> Hi, > >> > >> This series enables objtool to start doing stack validation on arm64 > >> kernel builds. > > > > Could we elaborate on this point, please? 'Stack validation' means > > getting an accurate picture of all kernel code that will be executed > > at some point in the future, due to the fact that there are stack > > frames pointing to them. And this ability is essential in order to do > > live patching safely? > > > > If this is the goal, I wonder whether this is the right approach for > > arm64 (or for any other architecture, for that matter) > > > > Parsing/decoding the object code and even worse, relying on GCC > > plugins to annotate some of the idioms as they are being generated, in > > order to infer intent on the part of the compiler goes *way* beyond > > what we should be comfortable with. The whole point of this exercise > > is to guarantee that there are no false positives when it comes to > > deciding whether the kernel is in a live patchable state, and I don't > > see how we can ever provide such a guarantee when it is built on such > > a fragile foundation. > > > > If we want to ensure that the stack contents are always an accurate > > reflection of the real call stack, we should work with the toolchain > > folks to identify issues that may interfere with this, and implement > > controls over these behaviors that we can decide to use in the build. > > In the past, I have already proposed adding a 'kernel' code model to > > the AArch64 compiler that guarantees certain things, such as adrp/add > > for symbol references, and no GOT indirections for position > > independent code. Inhibiting optimizations that may impact our ability > > to infer the real call stack from the stack contents is something we > > might add here as well. > > > > I'm not familiar with toolcahin code models, but would this approach be > able to validate assembly code (either inline or in assembly files?) > No, it would not. But those files are part of the code base, and can be reviewed and audited. > > Another thing that occurred to me is that inferring which kernel code > > is actually live in terms of pending function returns could be > > inferred much more easily from a shadow call stack, which is a thing > > we already implement for Clang builds. > > > > I was not familiar with the shadow call stack. If I understand correctly > that would be a stack of return addresses of function currently on the > call stack, is that correct? > > That would indeed be a simpler approach, however I guess the > instrumentation has a cost. Is the instrumentation also available with > GCC? And is this instrumentation efficient enough to be suitable for > production builds? > I am not aware of any plans to enable this in GCC, but the Clang implementation is definitely intended for production use (it's a CFI feature for ROP/JOP mitigation) > If we can rely on shadow call stack to implement the reliable unwinder, > I guess this could be the way to go. > > > In summary, I would not be in favor of enabling objtool on arm64 at > > all until we have exhausted other options for providing the > > functionality that we need it for (given that objtool provides many > > other things that only x86 cares about, IIUC) > > > I understand the concern and appreciate the suggestion. I guess this > does need some thorough discussions for the right approach. > Agreed. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel