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 C0F2EC433DB for ; Thu, 21 Jan 2021 13:29:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8AC0F206F7 for ; Thu, 21 Jan 2021 13:29:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729361AbhAUN2H (ORCPT ); Thu, 21 Jan 2021 08:28:07 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:37809 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732205AbhAUNZ1 (ORCPT ); Thu, 21 Jan 2021 08:25:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1611235438; 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=cvCR/SJT7x/0z+1fK/OgzO3ZsWGWZSRqQrMopnsNWp8=; b=T+7BZodwH+s5uNb6IgziWkF2rTEj8/CI9DjoNaI8nvlQ9Nqzi24xA3yXBm7B/1iPEq3KMz pojsXC6+BragRoFK4CJ75+2VQ9Ji6fo5iw8VFLrgi26OezYha8pS2imRgMqtQpOVokI8L8 4kkz/8bbL1/gt8kJRUJaxIiYlf34Xnk= 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-72-eft2UYMGPSytmiLanXDPQw-1; Thu, 21 Jan 2021 08:23:56 -0500 X-MC-Unique: eft2UYMGPSytmiLanXDPQw-1 Received: by mail-wr1-f72.google.com with SMTP id v7so1010711wra.3 for ; Thu, 21 Jan 2021 05:23:56 -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=cvCR/SJT7x/0z+1fK/OgzO3ZsWGWZSRqQrMopnsNWp8=; b=JtET2dCwHujbGz772lnLH6ap1Go61IOZFqrC3iTmUFoVjzPDz7AmFQCG6KV6bE5lbL xuE/bEkrqMynMFYEnvJUNlIalQJCIqcYy01oaljlMyM6ZSyYnwKPXXg1r3yDzNW2N+LK Vl6jGIQzgg9SDd750ItpGi4tCS+SqumhJ/y0Vn/jKQc2YyYT6KN7QBCQ0ebONJ4mOKlG UtqTbqKH5EhhBWM4aib5MD8c/9Ntpum5Jw827816b4MJZ10WbQUkf36NuZR+MMUTVFyS oKHtRaoTV4YhBkcmEhEiNKx8bOEMEE9vHImqxrxlwI5Xs2V0ptfHNXhFQ24Ny/OWlBgv UH9w== X-Gm-Message-State: AOAM533vXZ/RsswUKaMGYKPXiYlJlQFY1YC7bbRQ2Ujp2iLnvq8wuJEG EIGvJbo7R+B2p2C4SRVALtghR0zrroPGhgirbal8Qq5DvNzmXoS+EsFhlLwGpqxq2GdiIdYLeDH 4yOE/Ux6a5Qcir4F1eaCvFtd8 X-Received: by 2002:adf:c18d:: with SMTP id x13mr14020216wre.128.1611235435255; Thu, 21 Jan 2021 05:23:55 -0800 (PST) X-Google-Smtp-Source: ABdhPJz+HMrNE/GzNA0eRvoWZynPl2cm00oo1pYl3yrQV7e/rEXRQYgFCSqJngzxT5WNmFeOF92XUQ== X-Received: by 2002:adf:c18d:: with SMTP id x13mr14020198wre.128.1611235435102; Thu, 21 Jan 2021 05:23:55 -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 d30sm9999764wrc.92.2021.01.21.05.23.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 21 Jan 2021 05:23:54 -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> <186bb660-6e70-6bbf-4e96-1894799c79ce@redhat.com> From: Julien Thierry Message-ID: <6e21cd51-017e-2135-ed9d-33a60f22a457@redhat.com> Date: Thu, 21 Jan 2021 14:23:53 +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 On 1/21/21 12:08 PM, Ard Biesheuvel wrote: > 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. > That means that every actor maintaining their own stable version of the kernel have to do their own audit when they do backports (assuming the audit would be done for upstream) to be able to provide a safe livepatching feature in their kernel. >>> 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) > I think most people interested in livepatching are using GCC built kernels, but I could be mistaken (althought in the long run, both compilers should be supported, and yes, I realize the objtool solution currently only would support GCC). I don't know how feasible it will be to get it into GCC if people decide to go with that. Also, now that I think about it, it will probably come with similar limitations as stackframes where the unwinder would need to know when/where the shadow call stack is unavailable for some reason and the stack trace is not reliable. (it might be a bit simpler to audit than stack frame setting and maybe have less limitations, but I guess there will still be cases where we can't rely on it) -- 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 71B6FC433DB for ; Thu, 21 Jan 2021 13:25:47 +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 1EE7620691 for ; Thu, 21 Jan 2021 13:25:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1EE7620691 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=/joNvSaiFtoRIIC+Aowd1pWBiuJYUN9QZvAPp0ktE6g=; b=n4tF0QrBv8SHjkRTm+00N3N7W X9ES/+mvLKB3Tog1NEopZP8U2UR0gegtacGvdfVkRA1OIr20nU+/245Kea6BJa51bRcLUpgLUN4yy 6tq/F5NRXQ6p6/D6PDJOTFXdgJO2DuPrhTxysUDqjrzcSYtHK/kB1rD8fcEaVJQmfrcKCDQaevlvw WnPRM808CFpnwr7HYgKRKyEB7O5mFnG4GSBAWww6DvxNAtXNNEJsYwQF+Zsgj+0Dlc8nUv4RaW2gY K8/CP8r0HeQsPj14OZEJ1LFGvPlgI4BUfdJn/DUkLJndGyb5/xBOI6ZOKfn+xhzDXh60E/oMAORth 5+KRC+1Ug==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l2ZwR-0006mK-9V; Thu, 21 Jan 2021 13:24:03 +0000 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1l2ZwN-0006ki-3R for linux-arm-kernel@lists.infradead.org; Thu, 21 Jan 2021 13:24:00 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1611235438; 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=cvCR/SJT7x/0z+1fK/OgzO3ZsWGWZSRqQrMopnsNWp8=; b=T+7BZodwH+s5uNb6IgziWkF2rTEj8/CI9DjoNaI8nvlQ9Nqzi24xA3yXBm7B/1iPEq3KMz pojsXC6+BragRoFK4CJ75+2VQ9Ji6fo5iw8VFLrgi26OezYha8pS2imRgMqtQpOVokI8L8 4kkz/8bbL1/gt8kJRUJaxIiYlf34Xnk= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-446-oUonjh5IN3G1nG0Kfi1-cA-1; Thu, 21 Jan 2021 08:23:56 -0500 X-MC-Unique: oUonjh5IN3G1nG0Kfi1-cA-1 Received: by mail-wr1-f71.google.com with SMTP id y4so1005281wrt.18 for ; Thu, 21 Jan 2021 05:23:56 -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=cvCR/SJT7x/0z+1fK/OgzO3ZsWGWZSRqQrMopnsNWp8=; b=cRbhynZeGiI3DiKSMxg42W70+Y6hPtyeKHB6nG+av6g4SROZyXrG0Yfn3FgwqrhZJS dLuUiV7e1VeFDJrrdzPfibzd4v/vyUcx9hnU8m5J0kT8feWQpnhecxv5rlMnPsEnF8wX ooVS1ggjYZ6drg8BZLsA70JKILNGHZA0vUftuif/XkKYmy7O05Ifk5UdW0boxP2RFJEb 5q/+dmkW3AuLpAFXTcZaJv+28qhsNVWAXfXYUQAFk53+497kh8jeiNhgcIaCXylE5sTd 9xEWtWRJ24WxakZsC7xWbTMM79cjY1iEPzX1kwbITUlSN8h/bZVnsdtvsOJ+5oY1S0b5 a07A== X-Gm-Message-State: AOAM530bPqlqqGMQUTGAjF20c3NFLjrwEU9vsiMVH48cb7BN64HK7ws/ /s0GyYkPXu2fybRkmPSarVp36sZnrSywWl8FPpFeSncsTgxXUVA/flKyCiXtQZtS8FbbvYZqAu+ wQDgkZYKoUz3SUSVKCwCmCFm3iLlmHwuTU+0= X-Received: by 2002:adf:c18d:: with SMTP id x13mr14020219wre.128.1611235435256; Thu, 21 Jan 2021 05:23:55 -0800 (PST) X-Google-Smtp-Source: ABdhPJz+HMrNE/GzNA0eRvoWZynPl2cm00oo1pYl3yrQV7e/rEXRQYgFCSqJngzxT5WNmFeOF92XUQ== X-Received: by 2002:adf:c18d:: with SMTP id x13mr14020198wre.128.1611235435102; Thu, 21 Jan 2021 05:23:55 -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 d30sm9999764wrc.92.2021.01.21.05.23.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 21 Jan 2021 05:23:54 -0800 (PST) Subject: Re: [RFC PATCH 00/17] objtool: add base support for arm64 To: Ard Biesheuvel References: <20210120173800.1660730-1-jthierry@redhat.com> <186bb660-6e70-6bbf-4e96-1894799c79ce@redhat.com> From: Julien Thierry Message-ID: <6e21cd51-017e-2135-ed9d-33a60f22a457@redhat.com> Date: Thu, 21 Jan 2021 14:23:53 +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_082359_240454_0C2FCFBA X-CRM114-Status: GOOD ( 35.08 ) 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 On 1/21/21 12:08 PM, Ard Biesheuvel wrote: > 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. > That means that every actor maintaining their own stable version of the kernel have to do their own audit when they do backports (assuming the audit would be done for upstream) to be able to provide a safe livepatching feature in their kernel. >>> 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) > I think most people interested in livepatching are using GCC built kernels, but I could be mistaken (althought in the long run, both compilers should be supported, and yes, I realize the objtool solution currently only would support GCC). I don't know how feasible it will be to get it into GCC if people decide to go with that. Also, now that I think about it, it will probably come with similar limitations as stackframes where the unwinder would need to know when/where the shadow call stack is unavailable for some reason and the stack trace is not reliable. (it might be a bit simpler to audit than stack frame setting and maybe have less limitations, but I guess there will still be cases where we can't rely on it) -- Julien Thierry _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel