From patchwork Wed Feb 10 18:03:16 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Catalin Marinas X-Patchwork-Id: 380234 Delivered-To: patch@linaro.org Received: by 2002:a02:b18a:0:0:0:0:0 with SMTP id t10csp1389904jah; Wed, 10 Feb 2021 10:06:53 -0800 (PST) X-Google-Smtp-Source: ABdhPJzSwHWfFids1k4o0bGhWg9bmMdB0QZaE65j0PcQUbj4aRVfEdTdVP0B/oWcYnmPoB0Nxh91 X-Received: by 2002:a50:fd97:: with SMTP id o23mr4347218edt.306.1612980413045; Wed, 10 Feb 2021 10:06:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612980413; cv=none; d=google.com; s=arc-20160816; b=X4vzbz1gNP5V8uqbd618PPm3ufWpQioCmWZYVtkI/Zz33eSlZK7S++xztsFgt464t4 TJTtVlVfmIVG6qLG5QpqnhhQrZuu8XreX+UPlGPZDH9m7uagVu8UW0vvoOKRBkGJm9KZ XHSqCl6vC6e4jwzDb11kOKHs2wj6wAqsmRPEO6FIIVP+ukqi0W4ak9ZZJWQDMBh3h7BX ETek6XWb9yltE/0zn4g5pH9exApapb1qvijGMnmDeH3OEm0YiW+BO9hUniOndgApc4MG JtHWiNrwbvO3BPIP4Af2zTmADelws8eGgnPuwlczQ2dAvAYEpiGl/yZDf2fd0JJS6DN5 Inuw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=Wygsm/b8Ip/zYppR4PIoi+YuxltFrNLnYGFJ4aXyNtA=; b=Dx7Hvj/0Lcr4jmGpFZWTntDVKrBtCV2ttXyaTJRKh1TWkauEKN6ZygF6AHquCMBqCS z9wdo00Xc5cZKei9NMTGbncZUVarRjgwaKnxvcBBFG0a1d5uVgGw/e1AvlmrLxlmox+S iAAyxPX837IKyyrJFtUm41473lNqCKeee2CWHTv6e4RGGtXoVBO0MZE3vJ9tqnGXrucM sECGucB9mGJwwsDMSSD10ZMeptUqpdKVvEfAw2HrHYQRqJdcNRaKGBFJN5jnCwZQZEOi bo2Hht2EQQbX6T//QK0v/BQSbC8sdp3ngQFhzHfVfknKfakEw3dMQAQg05ZX/N15D8DE 2QuA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of stable-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=stable-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q18si2113451eji.611.2021.02.10.10.06.52; Wed, 10 Feb 2021 10:06:53 -0800 (PST) Received-SPF: pass (google.com: domain of stable-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of stable-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=stable-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233692AbhBJSGW (ORCPT + 13 others); Wed, 10 Feb 2021 13:06:22 -0500 Received: from mail.kernel.org ([198.145.29.99]:54914 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232750AbhBJSEA (ORCPT ); Wed, 10 Feb 2021 13:04:00 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id A04FA64ED7; Wed, 10 Feb 2021 18:03:18 +0000 (UTC) From: Catalin Marinas To: linux-arm-kernel@lists.infradead.org Cc: Luis Machado , Kevin Brodsky , Vincenzo Frascino , Steven Price , stable@vger.kernel.org, Will Deacon Subject: [PATCH] arm64: mte: Allow PTRACE_PEEKMTETAGS access to the zero page Date: Wed, 10 Feb 2021 18:03:16 +0000 Message-Id: <20210210180316.23654-1-catalin.marinas@arm.com> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org The ptrace(PTRACE_PEEKMTETAGS) implementation checks whether the user page has valid tags (mapped with PROT_MTE) by testing the PG_mte_tagged page flag. If this bit is cleared, ptrace(PTRACE_PEEKMTETAGS) returns -EIO. A newly created (PROT_MTE) mapping points to the zero page which had its tags zeroed during cpu_enable_mte(). If there were no prior writes to this mapping, ptrace(PTRACE_PEEKMTETAGS) fails with -EIO since the zero page does not have the PG_mte_tagged flag set. Set PG_mte_tagged on the zero page when its tags are cleared during boot. In addition, to avoid ptrace(PTRACE_PEEKMTETAGS) succeeding on !PROT_MTE mappings pointing to the zero page, change the __access_remote_tags() check to (vm_flags & VM_MTE) instead of PG_mte_tagged. Signed-off-by: Catalin Marinas Fixes: 34bfeea4a9e9 ("arm64: mte: Clear the tags when a page is mapped in user-space with PROT_MTE") Cc: # 5.10.x Cc: Will Deacon Reported-by: Luis Machado --- The fix is actually checking VM_MTE instead of PG_mte_tagged in __access_remote_tags() but I added the WARN_ON(!PG_mte_tagged) and setting the flag on the zero page in case we break this assumption in the future. arch/arm64/kernel/cpufeature.c | 6 +----- arch/arm64/kernel/mte.c | 3 ++- 2 files changed, 3 insertions(+), 6 deletions(-) Reviewed-by: Vincenzo Frascino diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c index e99eddec0a46..3e6331b64932 100644 --- a/arch/arm64/kernel/cpufeature.c +++ b/arch/arm64/kernel/cpufeature.c @@ -1701,16 +1701,12 @@ static void bti_enable(const struct arm64_cpu_capabilities *__unused) #ifdef CONFIG_ARM64_MTE static void cpu_enable_mte(struct arm64_cpu_capabilities const *cap) { - static bool cleared_zero_page = false; - /* * Clear the tags in the zero page. This needs to be done via the * linear map which has the Tagged attribute. */ - if (!cleared_zero_page) { - cleared_zero_page = true; + if (!test_and_set_bit(PG_mte_tagged, &ZERO_PAGE(0)->flags)) mte_clear_page_tags(lm_alias(empty_zero_page)); - } kasan_init_hw_tags_cpu(); } diff --git a/arch/arm64/kernel/mte.c b/arch/arm64/kernel/mte.c index dc9ada64feed..80b62fe49dcf 100644 --- a/arch/arm64/kernel/mte.c +++ b/arch/arm64/kernel/mte.c @@ -329,11 +329,12 @@ static int __access_remote_tags(struct mm_struct *mm, unsigned long addr, * would cause the existing tags to be cleared if the page * was never mapped with PROT_MTE. */ - if (!test_bit(PG_mte_tagged, &page->flags)) { + if (!(vma->vm_flags & VM_MTE)) { ret = -EOPNOTSUPP; put_page(page); break; } + WARN_ON_ONCE(!test_bit(PG_mte_tagged, &page->flags)); /* limit access to the end of the page */ offset = offset_in_page(addr);