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 DF90FC54EE9 for ; Tue, 13 Sep 2022 20:33:41 +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: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=Q9iNn52o+FX17/EHMgL2Dy/VO6mM5h1lrN0s2WT/fTw=; b=kWlWCHlwGhJ6kg LAdyUeyI9nSKy0Adj74fn+jEQHe+El3O2bE8EIGl4d6HvSn1x/QXjTNm251bI5YnczAMtesKBChTc xOGjd9syn3mLf1q/6I0TBmGqSOUBaUzJ7W9m1XMe8I1/h94IGXUsF/BZIpF3BuwAX6m4jbGXAHlVa LMalYhIdDZoUlc3KVG6crvhjpOa6jJfCmFh1fybFuhKI8vAYtZ0zUstIfLNMh5Z0hK6hsiRqxTEAV QdbqdHTLzIdPfY2wwEwEsv+zwwWVcW8hpx+0RfUpIFhHhvf+Bo7EH/GCN6y99LA5stdnuTGc5VFVy ftHgfW6hY5SXSKdY0b5A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oYCa1-00GJXE-AN; Tue, 13 Sep 2022 20:32:25 +0000 Received: from mail-wm1-x32d.google.com ([2a00:1450:4864:20::32d]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oYCZx-00GJTz-Pz for linux-arm-kernel@lists.infradead.org; Tue, 13 Sep 2022 20:32:23 +0000 Received: by mail-wm1-x32d.google.com with SMTP id n17-20020a05600c501100b003a84bf9b68bso10227538wmr.3 for ; Tue, 13 Sep 2022 13:32:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=W/kNFX+UVsRhlfnnY6LZ31QHfXkEmRJPKTrlmwQLsJs=; b=kziS82AbXi/57DWxCf8M6fB5OPjfu63b3vSVvnVq6N1kz2Hfv7c+GOY0ZTXSfDn7YX U+3iYdEACy7SvfY3aLRDadKRGacO5GfMKJ53jsBNEYVoQvCf2OQeapm8tlXPz/BtCyEv rhpUWjI5ZO327bppN/ti0OzJLvdyuGIJvFfQOkZaSn+ILUObT6bNIiBUlNSOhc/5HY5D T6Utr72Y6EEY9imTyQ8XxfvpqOvVr2kaeOcX0wmx5aykW0MMjQZx0Y+LHpX5Er2syPaw TqAudyV5rBl6sOaebOLGhlOpq7h065e8lO6tBLpw0+oUpyjM6fIkdeKUw4ElrBFLu7bq 6ZOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=W/kNFX+UVsRhlfnnY6LZ31QHfXkEmRJPKTrlmwQLsJs=; b=hbkCkNNVe11+cWtmaGVXlpBoMkazK2194DMCBZ+1LJlU5TbHbDEptwZrz3VpA3IXo2 LDFB2592nvKkVA6sU1xzjOUqIG5ZEcqhA09P2ARlMFDiBAnvKb2riWcE5wXHT86Ojtpq aucaz3vx0Yxl1k/K4AGHEZxhR5jNQiLbvNGQb5AuA7Rr4HPrDYLYDAr9UltE7f3zqRxL aT574wFURRR/5rgJDtxHKoMXJB740zl/dP2eoxddRQvDhuBWTeIN87OOvOEiX6hDCrGB Gkg01U1V9+EPvZeQEyx9U2hbr0r5F/VWpbi+IL0rZKqhpIc520Nec3ev8NZVc5FTq5BR 8KTA== X-Gm-Message-State: ACgBeo3caIPwdSxo4fxaCZo3eXVXqdxcXGewV2+Gl7Y/gkqLjVHFfV99 OK8uCJoVHtuBPQ+gq4gwY2oOr3K7Q6h2G0PP/0tWCw== X-Google-Smtp-Source: AA6agR7Y4yGI+hyJHUTfBkzK9VwzQ4shU8Zx9Y9evja4YN+GdEZJYsRJHnAv25itPUGrA53PzzFYe0BNgWBsby9kRQw= X-Received: by 2002:a05:600c:4f0e:b0:3a6:3395:ec12 with SMTP id l14-20020a05600c4f0e00b003a63395ec12mr693351wmq.181.1663101138470; Tue, 13 Sep 2022 13:32:18 -0700 (PDT) MIME-Version: 1.0 References: <20220907003630.1115439-1-eugenis@google.com> In-Reply-To: From: Peter Collingbourne Date: Tue, 13 Sep 2022 13:32:07 -0700 Message-ID: Subject: Re: [PATCH v4] arm64: mte: move register initialization to C To: Catalin Marinas Cc: Evgenii Stepanov , Kenny Root , Marc Zyngier , Will Deacon , Vincenzo Frascino , Andrey Konovalov , Mark Brown , Linux ARM , LKML , kernel test robot X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220913_133221_881960_35B62B93 X-CRM114-Status: GOOD ( 37.37 ) 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, Sep 12, 2022 at 1:04 PM Catalin Marinas wrote: > > On Fri, Sep 09, 2022 at 05:54:13PM -0700, Peter Collingbourne wrote: > > On Tue, Sep 6, 2022 at 5:36 PM Evgenii Stepanov wrote: > > > If FEAT_MTE2 is disabled via the arm64.nomte command line argument on a > > > CPU that claims to support FEAT_MTE2, the kernel will use Tagged Normal > > > in the MAIR. If we interpret arm64.nomte to mean that the CPU does not > > > in fact implement FEAT_MTE2, setting the system register like this may > > > lead to UNSPECIFIED behavior. Fix it by arranging for MAIR to be set > > > in the C function cpu_enable_mte which is called based on the sanitized > > > version of the system register. > > > > > > There is no need for the rest of the MTE-related system register > > > initialization to happen from assembly, with the exception of TCR_EL1, > > > which must be set to include at least TBI1 because the secondary CPUs > > > access KASan-allocated data structures early. Therefore, make the TCR_EL1 > > > initialization unconditional and move the rest of the initialization to > > > cpu_enable_mte so that we no longer have a dependency on the unsanitized > > > ID register value. > > > > Moving the register initialization to C also fixes a bug where the > > kernel's zeroing of TFSR_EL1 has no practical effect when the kernel > > is started in VHE mode because the register is currently being zeroed > > prior to the kernel enabling the redirect of TFSR_EL2 to TFSR_EL1 when > > it enables VHE. As a result, without this patch it is possible to get > > a spurious KASAN error report if TFSR_EL2 is non-zero out of reset. > > Oh, I think this is a side-effect of the nVHE patches. We added MTE in > 5.10 and __cpu_setup() was called at EL2 if the kernel was entered at > EL2 - 3b714d24ef17 ("arm64: mte: CPU feature detection and initial > sysreg configuration"). When nVHE turned up in 5.12, this was changed to > to run __cpu_setup at EL1 and this only initialises TFSR_EL1. > __finalise_el2 should have transferred TFSR_EL12. > > I don't think there other registers we missed in __cpu_setup() but I > haven't looked in detail. > > So for this, we either move the reg initialisation to C or we fix > __finalise_el2. I'm tempted to go with the former as long as the kernel > doesn't read that register up to that point and complain of a spurious > asynchronous fault. Yes, I don't think we can generally expect the kernel to read the register up to that point. The register is generally only read in response to an exception, and the early kernel initialization code runs with interrupts disabled and only enables them well after the call to smp_prepare_boot_cpu() for the primary CPU (see the calls to local_irq_disable() and local_irq_enable() in start_kernel()) and check_local_cpu_capabilities() for the secondaries (see the call to local_daif_restore() in secondary_start_kernel()), so unless something has gone seriously wrong that would cause us to get a synchronous exception that early (in which case the spurious async fault report is the least of our worries) I don't think we should expect to see one of these reports as a result of moving the initialization code to C. Peter _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel