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 9E4D9C43334 for ; Thu, 7 Jul 2022 19:37:17 +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=5xdqcyuFkHMh7U5mWjqE6t1Iq5yCDKMHgurrDc7Ko34=; b=m0F+fITlf4oUj9 46CyrCzf5e3wsQ9AD5w4rM3IooUF789xnOVhh1GPctfAUwbUYvGmURGNS4+Do/WUsoq9aE/qJEkdQ GO111zGFnlL7wohNKRjqD6/r7wKd7XpjWoXwl8Fq6uZ6ZZiIZ4cp2RHxJWb8D9SlHGq2RzXNL6h/v kHegRwvpaLU9Pv6VuglJdxvxZXuHnVpAeAuOZzaeu2/HXralq9rOqE1QaIDqPsxD9jjtlIqXnyN9D P6HpW3KacnQu3CmITNW5bIR7o5q69ZXGP2P63ORRJvqgg3YbWolqzYfos2ssYdAzQzpdF1ZD/v8is /PWIw3inLIsYp7ZozL+Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1o9XIK-00HZNy-Ar; Thu, 07 Jul 2022 19:36:12 +0000 Received: from mail-pg1-x529.google.com ([2607:f8b0:4864:20::529]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1o9XIH-00HZNX-Vk for linux-arm-kernel@lists.infradead.org; Thu, 07 Jul 2022 19:36:11 +0000 Received: by mail-pg1-x529.google.com with SMTP id i190so7701022pge.7 for ; Thu, 07 Jul 2022 12:36:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=ncWUfFPhAlXdPrKYt/f5jj3VBpNETHxNQZd4avh1ogo=; b=m6CWhvPiUh/R1aHF1cAXI6Fd5MbNduHw9mjgzTwquipmC5ExqNqn7jXG6fOrBAYMld 6hfI9S5lPuVV4a2VxjpiehpyhuaQbnS1xGggGJDLBmVgtTsD08y6fSb5x3IJPCCiwQx+ KGPS0Eg3k+V93wmJo32OJRqjaARLt5N89ckzkooQurlPjtVSX6PsBxDhR+PdRBnBNmnO 13Bx316iyoP5aOBsz5nav6FeUHD7sMkFWkifEf+dXrgnGtGtuocLurlEb4T9P4KQDYJP rt0lXo+fw/CrtMFlB8VibiCpwvvOGyhaq93os3fXjip8YXhrKovPhh6amSxQDST904K7 2aUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=ncWUfFPhAlXdPrKYt/f5jj3VBpNETHxNQZd4avh1ogo=; b=1QtZpvZQJxSNZGT84z9eleFqc73rSTX7sSEtwvYd+nOReGtX6TYbNvklGAj5fU2vQX Xd0BjpIABEp+h+zYytNfXb1FKfuQ7Vtg+pS5am/jD8CGYo38pvunUjvlaH8JfSgiyoeq gSQUYc5DRu1GbrQXCC0B3pOMY1AjHQn+mkbanXHddHhhByHjI6qyVKMqqM9DNLUiLXVm O8FuO3WgAHRr7KO572voeCjZy7COPPCg9Eck6qe9kpvCFTj5Dv9gJCXQd1p227e3Nfa8 lEAr/qbJaoJfYvHlleF5OtAyp8LOZRuCbi88PXvXDN6DJjgr9hLLE6apP8CqrWpXDoAc Z2ww== X-Gm-Message-State: AJIora+RLU2ADiPHTGZl2TDmzu3eGBCl+Ki3fpkXh7xyEdedX2kTQknm STCsEqyDQSdBQuh/znyQTxfMgbbJasj8ig== X-Google-Smtp-Source: AGRyM1uupv6mqPt87firI80jQx+W0XQ6r3qeaZW83UPXwI3Xx75/Yh2qk8Npjun//YwEZvQgHwvB0A== X-Received: by 2002:a17:902:e54a:b0:16a:3e90:3cdc with SMTP id n10-20020a170902e54a00b0016a3e903cdcmr52804777plf.38.1657222565452; Thu, 07 Jul 2022 12:36:05 -0700 (PDT) Received: from google.com ([2620:15c:201:2:b99:92df:51a8:2a1d]) by smtp.gmail.com with ESMTPSA id d11-20020a170903230b00b0016a5384071bsm28484484plh.1.2022.07.07.12.36.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Jul 2022 12:36:05 -0700 (PDT) Date: Thu, 7 Jul 2022 12:35:58 -0700 From: Sami Tolvanen To: Ard Biesheuvel Cc: linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com, will@kernel.org, mark.rutland@arm.com, maz@kernel.org Subject: Re: [PATCH v4 0/3] arm64: dynamic shadow call stack support Message-ID: References: <20220701152724.3343599-1-ardb@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220701152724.3343599-1-ardb@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220707_123610_065196_E1B77D14 X-CRM114-Status: GOOD ( 26.24 ) 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 Hi Ard, On Fri, Jul 01, 2022 at 05:27:21PM +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 be able to unwind call stacks that involve return address > signing, whether or not the return address is currently signed is > tracked by 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 recently been > fixed to emit all these CFI directives correctly. This series is based > on an older PoC sent out last year [0] that targeted GCC only (due to > this issue). This v3 targets Clang only, as GCC has its own issues with > CFI accuracy. > > Changes since v3 [1]: > - rebase onto arm64/for-next/core Btw, this no longer seems to apply cleanly to for-next/core. I've found using git format-patch --base=auto helpful when sending patches against trees that change more frequently. > - fix init value of dynamic_scs_enabled static key > - don't discard .eh_frame sections (to work around a bug in an older > Clang version if we are keeping them for dynamic SCS patching, > - print a diagnostic if dynamic SCS patching is enabled, > - apply build fix suggested by Sami and add his ack to patch #2 Nevertheless, the patches look good to me, and SCS was correctly enabled on CPUs without PAC support in my testing. For the series: Reviewed-by: Sami Tolvanen Tested-by: Sami Tolvanen Sami _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel