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 35647C54EE9 for ; Wed, 7 Sep 2022 17:26:53 +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:MIME-Version:References: Message-ID:Subject:Cc: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=KzXI4ouRF7aI0EkbnRAxyJKMwuQS/om8wTdk0+KMs6Y=; b=0RQDKqNmu0BHuA kKOpEUPyDm2EABjn9TNgepzUg3L7i9ixqtkhUK6vLtO2SQ+G5PL+3vrVB59lK4oN8ZB6gCI90lyDz E2mLr3SL57FJKfyuRrGagzXI997CJomtFzmkICiNpUXbn+D8PKwn4SqZmbbo7tR19v4gzDiRS56/P U+vcu3s7DO78GQ4rMFaB/P4ucHi6Nw78eNuByBLr28ajQsmV95eiE5k/LMKFZGSNJRsyzE8OJWyc3 Xa/l5LLCMrFAqXOe67KakgGJRxVu+ZuDyP/rue5gPGIeVRnrwwYQp2eYSwe5V5iOySjtHdc9elN1Y KELoAk5IJiwAXbSSEHdg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oVyoA-008D1Y-MI; Wed, 07 Sep 2022 17:25:50 +0000 Received: from mail-pj1-x1033.google.com ([2607:f8b0:4864:20::1033]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oVyo7-008Cxo-Hv for linux-arm-kernel@lists.infradead.org; Wed, 07 Sep 2022 17:25:48 +0000 Received: by mail-pj1-x1033.google.com with SMTP id z9-20020a17090a468900b001ffff693b27so14119185pjf.2 for ; Wed, 07 Sep 2022 10:25:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date; bh=QiAnjJtYGv8kUydliPsY7zKADXeCYg2xIK/n4eTFvNI=; b=aWJ3estw0Z+tNAd49zJpw5sU3dQtGvZ0bthBP65qmCnubtx0QQ0odW/DKLVTv1GSAl ak+cmLr8Z4v3OyRVRcE2yaSj7yVmXmtgTxu1Skz+AVA8y2urovm/wCPqaH8Fmy+F/KOe rMzcqO0Zol2D4vsO7OkQOHHKOYpjmvHJrYDt0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date; bh=QiAnjJtYGv8kUydliPsY7zKADXeCYg2xIK/n4eTFvNI=; b=4K2szVaVH4ObLAOE444wHi+OUzTN6ZrnkH8fruHeE6qdCKvwpVTb7YWSpcn33ET8kD X3nhnXXQqTKSF+ZqkHJvf8ukqIr9FmsWXn1+AyBTfblAQ/o48GPawbanr+YT/UZSOttO nr7wFtKCXPGY4HExwgPYIzCVxmloGQW/z1v4nxYkbx4Xfw18Pd0hOwCEF5VqAxkHNQ7c aGttP7zqhxE+dJ+4I0wlZeST/V2OvK9tUPsZFrpR/NWrlsbDoI4OUFsHXc8rUEJhm+uE ZQYR+K7pPURH8qS7HGVbczVpQs8LBsbxiwml5TDkGyFESCI09zRR/EOYWgmBlFtlcURA iJEg== X-Gm-Message-State: ACgBeo1MpUNBfbFT1PKMP3ip934mBEe7xtLWpPFfqzjfghQ5tRMFPiUI ZDZMi+PtLIx6mHsmev6uJrdbzg== X-Google-Smtp-Source: AA6agR5qeY3Xo1F9XZgxRg0GCyUlUC8bGJXlI840G7sAxBxNXB5Q7yNdZ18/SgfQP/89MHyXIhYMjg== X-Received: by 2002:a17:903:2c9:b0:172:57d5:d6f0 with SMTP id s9-20020a17090302c900b0017257d5d6f0mr4982051plk.61.1662571543854; Wed, 07 Sep 2022 10:25:43 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id n7-20020a170902d2c700b001709e3c755fsm5023133plc.230.2022.09.07.10.25.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Sep 2022 10:25:42 -0700 (PDT) Date: Wed, 7 Sep 2022 10:25:41 -0700 From: Kees Cook To: Catalin Marinas , Will Deacon Cc: linux-arm-kernel@lists.infradead.org, Ard Biesheuvel , Marc Zyngier , Mark Rutland , Mark Brown , Sami Tolvanen , Nick Desaulniers Subject: Re: [PATCH v5 0/3] arm64: dynamic shadow call stack support Message-ID: <202209071024.31CBA83C4@keescook> References: <20220822095058.2912704-1-ardb@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220822095058.2912704-1-ardb@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220907_102547_641020_34D4F5E0 X-CRM114-Status: GOOD ( 26.29 ) 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 Mon, Aug 22, 2022 at 11:50:55AM +0200, Ard Biesheuvel wrote: > Generic kernel images such as Android's GKI usually enable all available > security features, which are typically implemented in such a way that > they only take effect if the underlying hardware can support it, but > don't interfere with correct and efficient operation otherwise. > > For shadow call stack support, which is always supported by the > hardware, it means it will be enabled even if pointer authentication is > also supported, and enabled for signing return addresses stored on the > stack. The additional security provided by shadow call stack is only > marginal in this case, whereas the performance overhead is not. > > Given that return address signing is based on PACIASP/AUTIASP > instructions that implicitly operate on the return address register > (X30) and are not idempotent (i.e., each needs to be emitted exactly > once before the return address is stored on the ordinary stack and after > it has been retrieved from it), we can convert these instruction 1:1 > into shadow call stack pushes and pops involving the register X30. > As this is something that can be done at runtime rather than build time, > we can do this conditionally based on whether or not return address > signing is supported on the underlying hardware. > > In order to allow runtimes to unwind call stacks that involve return > address signing, we track whether or not the return address is currently > signed by means of DWARF CFI directives in the unwinding metadata. This > means we can use this information to locate all PACIASP/AUTIASP > instructions in the binary, instead of having to use brute force and go > over all instructions in the entire program. > > This series implements this approach for Clang, which has been vetted > (and fixed in release 15) to ensure that the unwind metadata is 100% > accurate when it comes to PACIASP/AUTIASP occurrences. Sadly, GCC does > not always get that quite right, so this series is Clang-only for the > moment. Will, Catalin, what's left for this series? I'd really to get this landed -- it's reviewed and tested, and will be used on real devices. Thanks! -Kees -- Kees Cook _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel