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=-7.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 43AECC433E6 for ; Thu, 21 Jan 2021 10:29:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E68FF238A0 for ; Thu, 21 Jan 2021 10:29:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729398AbhAUK33 (ORCPT ); Thu, 21 Jan 2021 05:29:29 -0500 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:49340 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729232AbhAUK2D (ORCPT ); Thu, 21 Jan 2021 05:28:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1611224785; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ioXqDDiFH1FLFozZBQ+HRIcOlQIXWLS3JcruiTjdisI=; b=B8qahuPcFsItxiAoc0BojRGvpNK8KZaxW1SRhPeED+uZjcqOl1q6WBRoqXWESiojl0lN6C KHDWBHEKNHu/5vU+ui7GidA3j00p2raXaLgIIylAeQnZPryVwovJwX2TiZDbMWacePUG8K TB25+oTBfFryD58kggBVXuMIzldlfw8= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-22-dm33LaqPPA2tgoaLyyCBPQ-1; Thu, 21 Jan 2021 05:26:23 -0500 X-MC-Unique: dm33LaqPPA2tgoaLyyCBPQ-1 Received: by mail-wr1-f69.google.com with SMTP id o17so737295wra.8 for ; Thu, 21 Jan 2021 02:26:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ioXqDDiFH1FLFozZBQ+HRIcOlQIXWLS3JcruiTjdisI=; b=IuSKKOHy2vQsLIwoB0ivWa511Oo35H1FPuHyNA3SHioXlfpPMzaxZ1HkaYK/c52uXD UTM74K6eA1dZM3yMzkM5zprPbhZ1HFjUbnlzaWq5MLQyW73FghvALqiMAwsafdVFZWy1 ZohOXWjuebxqT5aUZoQhtQBMAjLphbJwpvbBBQRpyVBHmE//QTRIz+5BwhbOidr/aVUE q652dNFl8c4RVnj4JGdVVWL9oLAK/M8pxVu6grehP797hFtnKgWhDIjmSqh1gX/wvCeP ioFATrELX0ZAMPiNZW4wcQ1pZx78K6kmosMtUfgo9uYkWA+wYPaa5ynxLyGCndebU63u nXUg== X-Gm-Message-State: AOAM532Oiw5i1nC4HR4ENvHmYciFbUxO6btN/PvgnQG2qNdCzNgA61sV nomQkz5EDSESVOTyjlZ3EoNWX9Xp+TBsL1YlG2wewLWiITcTAxHP3pJv1YvCj5Tatsd/pENe9VS 1iAFyYsEAWg7KT1BReWCJOXGY X-Received: by 2002:a1c:740b:: with SMTP id p11mr8434070wmc.34.1611224782065; Thu, 21 Jan 2021 02:26:22 -0800 (PST) X-Google-Smtp-Source: ABdhPJytwLyArMdkrGW2euiv2F5R+LcpKlJ7dFLk1oelXDZLOX3sUNvrSI1pLXYiudKjaGFuCBlfJQ== X-Received: by 2002:a1c:740b:: with SMTP id p11mr8434041wmc.34.1611224781804; Thu, 21 Jan 2021 02:26:21 -0800 (PST) Received: from ?IPv6:2a01:cb14:499:3d00:cd47:f651:9d80:157a? ([2a01:cb14:499:3d00:cd47:f651:9d80:157a]) by smtp.gmail.com with ESMTPSA id a6sm7378064wmj.27.2021.01.21.02.26.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 21 Jan 2021 02:26:21 -0800 (PST) Subject: Re: [RFC PATCH 00/17] objtool: add base support for arm64 To: Ard Biesheuvel Cc: Linux Kernel Mailing List , Linux ARM , Catalin Marinas , Will Deacon , Masahiro Yamada , Kees Cook , Michal Marek , Josh Poimboeuf , Peter Zijlstra , Mark Rutland , Mark Brown , linux-efi , linux-hardening@vger.kernel.org References: <20210120173800.1660730-1-jthierry@redhat.com> From: Julien Thierry Message-ID: <186bb660-6e70-6bbf-4e96-1894799c79ce@redhat.com> Date: Thu, 21 Jan 2021 11:26:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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?) > 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? 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. Thanks, -- Julien Thierry 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=-5.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 40A8EC433E0 for ; Thu, 21 Jan 2021 10:28:45 +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 D1633233EA for ; Thu, 21 Jan 2021 10:28:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D1633233EA 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-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=MweczpYYKcLE70gRXunt8MI3zbinS9BPaAsdW1lcv+k=; b=s+nSFTubhUK8Xt4EtGdNgzcR4 rUbZPLcYpZPC97c+tsubXKrtfQxpnI5m853Mxgwr4t3TsrLhowP+WWqGv349uZs8vdWiGUc6Ro9EM bilK1EJsam9v2xZ15fFXY4PxPOtyPQKrI2RC9C7VFUH4abH6HxNG04fJSmn9izpzFLEWF4GV1Pc8R aij08xUadAO94wn7YpsgL3W4F9STTjdeyYhOFNckwY/eX2Uwn10F1gUEn61N7ETYA4Xn+23AY/TQs yF6AInxJMQmO6xwGksDQABqL5Ibw/JGcl1tbJs7eT0JGuirCys9LKQQ9vk3d8onya2PY9uDpEER// IoVqDn0Lg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l2XAc-000446-L7; Thu, 21 Jan 2021 10:26:30 +0000 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1l2XAZ-00043H-R5 for linux-arm-kernel@lists.infradead.org; Thu, 21 Jan 2021 10:26:28 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1611224787; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ioXqDDiFH1FLFozZBQ+HRIcOlQIXWLS3JcruiTjdisI=; b=YxfUBMtSXdDksHCt8KOJ+LqqU2xtq4YHrtvHghi9cAvGSTI/cIz3uHHACJFB0vw5x7DsSu pV+WopejoOVwVEmBWAPokI4GVNq7mBB1Rk6cG/g/laGZdVVr6yRepaPvsVXwBez1JJR/14 IrypnzVHuavrt3lZpX2ceH2u6+5txvA= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-16-G_T46UjHPmyZd3MZ6mtKuQ-1; Thu, 21 Jan 2021 05:26:23 -0500 X-MC-Unique: G_T46UjHPmyZd3MZ6mtKuQ-1 Received: by mail-wr1-f72.google.com with SMTP id q18so726836wrc.20 for ; Thu, 21 Jan 2021 02:26:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ioXqDDiFH1FLFozZBQ+HRIcOlQIXWLS3JcruiTjdisI=; b=nPZ75K4seb/nim4+HigwFBTKvJtCbTYIbQqDx45myr8JhJ9O8SN6DVEPTkbJQKGJ9v Hoi9xsjoktO7yMIBExHndnDNmcuLemQWpbjPDxdfMl+JQKORGeyTHY/DFqWBcRV2iy1u dtmsTe81z8GU73wbSYAKgURlXLIW5RTC/FWCkLrQFa0nuEhI5eJbykWjLecKUvpE6AHC f6+g+i4sowRbai4Pm8tAwjagBsSQ3pB4HA6Y7CkyWqAb28xqjsRFFxMmrrsDOJCK2fRr wp65KdOQPlbFittX81ynMxtEFApky9Z/E4PwYfzLaNah0Sd1htQLgDlflAWuANs+qBTI b4gQ== X-Gm-Message-State: AOAM5338I733Es31sKInDWSmM6S0/sOhjmqDjsmbUZC3usJqUTMP4PkC HsAN6K4GOjsK5kL2PNYmwnVGdKu7/v7CfKqCXNvi9LnFroF0LDB0Qb8J62oe+L7Jy4ol0AEsWaz gQ6TUU7TxteRxklZLgpNm2xqlqU84nkjRv84= X-Received: by 2002:a1c:740b:: with SMTP id p11mr8434060wmc.34.1611224782020; Thu, 21 Jan 2021 02:26:22 -0800 (PST) X-Google-Smtp-Source: ABdhPJytwLyArMdkrGW2euiv2F5R+LcpKlJ7dFLk1oelXDZLOX3sUNvrSI1pLXYiudKjaGFuCBlfJQ== X-Received: by 2002:a1c:740b:: with SMTP id p11mr8434041wmc.34.1611224781804; Thu, 21 Jan 2021 02:26:21 -0800 (PST) Received: from ?IPv6:2a01:cb14:499:3d00:cd47:f651:9d80:157a? ([2a01:cb14:499:3d00:cd47:f651:9d80:157a]) by smtp.gmail.com with ESMTPSA id a6sm7378064wmj.27.2021.01.21.02.26.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 21 Jan 2021 02:26:21 -0800 (PST) Subject: Re: [RFC PATCH 00/17] objtool: add base support for arm64 To: Ard Biesheuvel References: <20210120173800.1660730-1-jthierry@redhat.com> From: Julien Thierry Message-ID: <186bb660-6e70-6bbf-4e96-1894799c79ce@redhat.com> Date: Thu, 21 Jan 2021 11:26:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=jthierry@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210121_052627_909753_FF67840A X-CRM114-Status: GOOD ( 36.76 ) 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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?) > 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? 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. Thanks, -- Julien Thierry _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel