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=-6.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, 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 51E17C4338F for ; Thu, 29 Jul 2021 17:53:08 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 1F0F960EE2 for ; Thu, 29 Jul 2021 17:53:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 1F0F960EE2 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org 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=9pFEVCLiKbKtPFj+Of1xz/nYaQKwjBjWgvFXzar+SuQ=; b=SpXGHvZgbcMTar atW709aUDHj81BhyBjtgg3EjthBEFvF2Ui6LfQ+cty9+7c4SVL9Hiymt9DVVkZbHB92eQMSsF6qZi P2eUrohVn2QY0D9JfXEN4vX6rCJkVpSJP8+zt6LrEQ26+Xxj+LTWe63rVHEMBNwhDKytE2ZeFnmd8 cqfLxaw/FRZgUZ1SiEC/kkyC2v+bNX+SVpA3UBuw7Y/ONebD+mc9BmfqI407O7SBpQLUuIWSdcywF 9JxqifrWyXr96hGyXh+oXrJu/W8DAEa6sAGVySCAmvHiCRd0ba07yTAzMxwJ5oPiXqWg03jcOK4g5 zxsDJBsS841bfXrZV/yQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1m9ABK-005QiN-Lw; Thu, 29 Jul 2021 17:50:55 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1m9A4t-005OUC-0p for linux-arm-kernel@lists.infradead.org; Thu, 29 Jul 2021 17:44:17 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 8A42360EE2; Thu, 29 Jul 2021 17:44:12 +0000 (UTC) Date: Thu, 29 Jul 2021 18:44:09 +0100 From: Catalin Marinas To: Peter Collingbourne Cc: Evgenii Stepanov , Kostya Serebryany , Vincenzo Frascino , Dave Martin , Will Deacon , Szabolcs Nagy , Linux ARM , Linux API Subject: Re: [PATCH v2] arm64: allow TCR_EL1.TBID0 to be configured Message-ID: <20210729174409.GC31848@arm.com> References: <20210622051204.3682580-1-pcc@google.com> <20210727165109.GB13920@arm.com> <20210728164219.GC7408@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210729_104415_175238_879C6349 X-CRM114-Status: GOOD ( 71.05 ) 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 Wed, Jul 28, 2021 at 04:50:07PM -0700, Peter Collingbourne wrote: > On Wed, Jul 28, 2021 at 9:42 AM Catalin Marinas wrote: > > On Tue, Jul 27, 2021 at 03:00:10PM -0700, Peter Collingbourne wrote: > > > On Tue, Jul 27, 2021 at 9:51 AM Catalin Marinas wrote: > > > > On Mon, Jun 21, 2021 at 10:12:04PM -0700, Peter Collingbourne wrote: > > > > > Introduce a command line flag that controls whether TCR_EL1.TBID0 > > > > > is set at boot time. Since this is a change to the userspace ABI the > > > > > option defaults to off for now, although it seems likely that we'll > > > > > be able to change the default at some future point. > > > > > > > > > > Setting TCR_EL1.TBID0 increases the number of signature bits used by > > > > > the pointer authentication instructions for instruction addresses by 8, > > > > > which improves the security of pointer authentication, but it also has > > > > > the consequence of changing the operation of the branch instructions > > > > > so that they no longer ignore the top byte of the target address but > > > > > instead fault if they are non-zero. > > > > > > > > I'm a bit uneasy about the ABI change and not so keen on constraining > > > > the ABI through the kernel command line. Ideally we should make this an > > > > opt-in per application (prctl()) but that has some aspects to address > > > > > > This doesn't necessarily need to be the end state, we can enhance this > > > based on need. For example, we could choose to take this patch now and > > > later implement the per-process opt-in where the default is controlled > > > by the command line. > > > > What's the risk of an application becoming reliant on the new mode > > (TBID0) and breaking with the old one? Probably very small but I haven't > > figured out if it's zero. Depending on whether we have PAC or PAC2 (the > > latter came with 8.6 but optional in 8.3) with TBID0, there are some > > differences on how the PAC/AUT instructions work and the code generated > > (XOR with the top bits). > > I think it would be quite small. On Android, at least to begin with > there would be a mixture of devices with different TBID0 settings > (devices without PAC support and devices with older kernels would all > have this disabled), so I think it would be difficult for an > application to depend on it being enabled. > > > > Or just implement the software-only per-process > > > TBID0 almost-disablement which would be much simpler than doing it in > > > hardware, if that is enough to satisfy future needs. > > > > I don't entirely follow this. > > Sorry, I was referring to my earlier proposal for recovering from > tagged PC in the kernel by clearing the tag bits: > https://lore.kernel.org/linux-arm-kernel/CAMn1gO7+_JhTUw2gS6jnyRV+TCqprmpuCAfee3RCAhNjoVyy9w@mail.gmail.com/ Ah, sorry, I missed this one (or just paged it out entirely over the holiday). > > > Otherwise we risk adding "unused" complexity to the kernel that we can > > > never remove due to API stability guarantees. > > > > We've had other debates over the years and, in general, if a kernel > > change causes apps to break, we'd have to keep the original behaviour. > > Are there any plans to fix the JITs tools you discovered? > > Yes, we would definitely want to fix the JIT issue in the Android > platform before rolling out a forward PAC ABI. This would be separate > from fixing apps, which would need to opt into MTE (or address tagging > via the target API level) anyway. But if it turns out that there are > too many apps with these JITs that use MTE or address tagging, I think > we would need to come back to the kernel to figure out some way to let > these programs run. OK, I guess we don't yet have a clear view on how many such apps are affected. > > Talking to Will about this he was wondering whether we could make TBID0 > > on by default and clear the tag in PC if we take a fault (on tagged PC), > > restarting the context. PAC shouldn't be affected since we would only > > branch to an authenticated (PAC code removed) pointer. If this works, > > we'd only affect performance slightly on such apps but don't completely > > break them. > > Right, this sounds exactly like my earlier proposal. Indeed. Something I haven't figured out yet is whether such handling in the kernel would weaken PAC. For example, following a failed AUT (the old style which does not trap), the resulting address would cause a translation fault. Would the kernel clearing the top byte result in a potentially valid address? > > > > first: (a) this bit is permitted to be cached in the TLB so we'd need > > > > some TLBI when setting it (and a clarification in the specs that it is > > > > tagged by ASID/VMID, probably fine) and (b) we'd need to context-switch > > > > TCR_EL1, with a small performance penalty (I don't think it's > > > > significant but worth testing). > > > > > > So TLBI all of the CPUs on prctl() and context-switch TCR_EL1? I > > > thought there would be DOS concerns with the first part of that? > > > > The DoS problem appears if we need to issue an IPI to all CPUs (like > > stop_machine). The TLBI with broadcast handled in hardware should be OK > > as it's targeted to a specific ASID. But this would have to be issued > > I see -- I hadn't realised that this instruction is implemented as a > broadcast. So we would just need to issue the instruction from any CPU > and we should be good. Well, as long as it's single-threaded when the prctl() is issued. If there are multiple threads, we'd have to synchronise all the CPUs. Such requirement is probably not a big deal anyway as it affects the return addresses, so it would have to be done early. > > before any app threads are started, otherwise we'd need to synchronise > > TCR_EL1. Given that TBID0 toggling affects PAC, this can only be done > > Right, so this would be different from everything currently in > tagged_addr_ctrl because it would be per-process rather than > per-thread. So if this were a true TBID0 control we may even want it > as a separate prctl() since there are certainly use cases for changing > the other bits of tagged_addr_ctrl while the other threads are > running. Since it's permitted to be cached in the TLB, switching it between threads would require TLBI on each switch, so not feasible. How early is the prctl(PR_TAGGED_ADDR_ENABLE) called? Anyway, it probably makes more sense to have a separate control since TBID0 is not necessarily linked to hwasan or MTE. We'd want more PAC bits even if hwasan or MTE are not deployed. > > safely very early in the application before return addresses get a PAC > > code. > > Right, so maybe the "almost-disablement" would work better since all > of the signatures would then still be valid, and you could even have > different settings for different threads if you wanted to (e.g. if you > arranged to run legacy code only on a specific thread). Yes, if (a) it doesn't weaken PAC and (b) there are no future plans to use code TBI as trapping would make it slower. I think we need to decide whether full TBI would be any useful going forward. One comment from Szabolcs on the previous version was that "data only tbi is a more complicated concept than plain tbi". Are there any tooling plans to benefit from code TBI? Or any use-cases that would be affected? For example, if we decide mmap() to return tagged pointers (with a new flag), would JITs want to benefit? If we need both data and code TBI to coexist, we should look into a per-process control. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel