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=-4.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 AC9F5C4338F for ; Wed, 28 Jul 2021 23:52:17 +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 6EC1D6101B for ; Wed, 28 Jul 2021 23:52:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 6EC1D6101B Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.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:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=9t4e14S8c9NsaLSR3FTrUAgLIArQl/y3QHvNW3IHoKY=; b=WK9b6bFEaSyL67 GhW9cTAESjUguIhNvtXaaCPEqWcnAE+uavKS9xLbBKaR82VxeU/fzzNKeCbPo/ODlu3uSHLGl3Br6 Xls7V0W631LptBHtoPNVz7baIowqAmOR4oEBAnkL+YmE/2PZ0MbepAq7RBQx/lPIgy7msEExABAEI jS5dM75NejM2kszIDf/jaIVMWFLwwQRgpaltGcENKZV1gLnCi9QROrsjSC7HsD4NxgUT884C7yZMW YvHyoPzhgE5LBmC75cCpwsPxpqq4B1fN63l28ae0yZXf1M47Plsam9q+aCJ9cTIYcHnCuiU+huYfy KjGj1LNLCg1WzuVL4HrQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1m8tJi-002cPL-Qv; Wed, 28 Jul 2021 23:50:27 +0000 Received: from mail-yb1-xb35.google.com ([2607:f8b0:4864:20::b35]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1m8tJe-002cO2-Fx for linux-arm-kernel@lists.infradead.org; Wed, 28 Jul 2021 23:50:24 +0000 Received: by mail-yb1-xb35.google.com with SMTP id p145so5864179ybg.6 for ; Wed, 28 Jul 2021 16:50:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ri7dkKO6h5RV/Ibe3NWL4402v4LTTBbbSPPGdrr9EWA=; b=JXqLLLKQ9B7Aib4nfyynUM9ac2AoEGdFAEcPjQMIKwvDcgOLzVYdf+qjF7FgO+/h9h +zYlReGNpSP0ophDpBZ0yGZPPsp7BeFOnQ+/m6ObpExwEA8SmdbkK2wSAwcwEXbWlKjt tboOqc29hiWTaGpc15cex24JduRM19DLsxcMfxQTIpOrecAVRnnQmAQdG/aaADAIEPlC gUq1eRL+K13UJtoBot6QOz5oMrq46S6mGevRYdYsmGjFBUVn4nYbRIS3PnKLfXF5ELn2 IYVOUBqdv8EFBIq//hQWUCvaO0EMzjoLycStVNkm5wPV50xaycsHzEoWo3YytDAgJKqf 6D/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ri7dkKO6h5RV/Ibe3NWL4402v4LTTBbbSPPGdrr9EWA=; b=D4i/iWlGpQY9sSITatr2buIskmCd8OsCnbqHoVDYNW1JFS8TiAjnzOBwyq+NA6pMSA 1QfV9UkY/zvV8HYuSUSfA00VEPpFzwA9TThuR2s8StenjUDH/Un5xv3xbrInCcMkKFZZ KtOZcy5p6G5gVDzDw6Ni0hfSQiWup0SWbFZUWNigWae8f/bigMIX2xJS+dCiXQuJ1m4x vqJRvHxDEy7N94gBMOGqNWrjika1I/SrklvDaDn5uHk8HqFgDLN1suLFwHxJFe82TsXM UlwZvXccBOLAakE9412429dUKNaCNo957jeWHKu3H7PGs+buo01ZXl6LpDvk5Erq2zyN dmcQ== X-Gm-Message-State: AOAM533AuDM9BYScOOed0ivIKLl6ZFdxtYpsz89wu4K0u7agg2Lz62E+ zH/vMn5GXeWum7t5uORoTKZvFT54A+cm2G+lJcct+g== X-Google-Smtp-Source: ABdhPJwaWRA1sv94hlkOc3Y+gpCGthbwr9k9FCG8Qb/Bs8BGo0KCxMQgxJPIc5XqICNw82VbJOR+Ix3caEe0YlKrUfM= X-Received: by 2002:a5b:648:: with SMTP id o8mr3120806ybq.260.1627516218334; Wed, 28 Jul 2021 16:50:18 -0700 (PDT) MIME-Version: 1.0 References: <20210622051204.3682580-1-pcc@google.com> <20210727165109.GB13920@arm.com> <20210728164219.GC7408@arm.com> In-Reply-To: <20210728164219.GC7408@arm.com> From: Peter Collingbourne Date: Wed, 28 Jul 2021 16:50:07 -0700 Message-ID: Subject: Re: [PATCH v2] arm64: allow TCR_EL1.TBID0 to be configured To: Catalin Marinas Cc: Evgenii Stepanov , Kostya Serebryany , Vincenzo Frascino , Dave Martin , Will Deacon , Szabolcs Nagy , Linux ARM , Linux API X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210728_165022_604611_A89350B2 X-CRM114-Status: GOOD ( 58.20 ) 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 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/ > > 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. > 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. > > > 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. > 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. > 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). Peter _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel