linux-kernel - Re: [PATCH v4 2/9] riscv: Restore the pfn in a NAPOT pte when manipulated by core mm code

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Z5ePZt61CM84Hb36@casper.infradead.org>
Date: Mon, 27 Jan 2025 13:51:34 +0000
From: Matthew Wilcox <willy@...radead.org>
To: Alexandre Ghiti <alexghiti@...osinc.com>
Cc: Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will@...nel.org>, Ryan Roberts <ryan.roberts@....com>,
	Mark Rutland <mark.rutland@....com>,
	Paul Walmsley <paul.walmsley@...ive.com>,
	Palmer Dabbelt <palmer@...belt.com>,
	Albert Ou <aou@...s.berkeley.edu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	linux-riscv@...ts.infradead.org, linux-mm@...ck.org
Subject: Re: [PATCH v4 2/9] riscv: Restore the pfn in a NAPOT pte when
 manipulated by core mm code

On Mon, Jan 27, 2025 at 10:35:23AM +0100, Alexandre Ghiti wrote:
> +#ifdef CONFIG_RISCV_ISA_SVNAPOT
> +static inline void set_ptes(struct mm_struct *mm, unsigned long addr,
> +			    pte_t *ptep, pte_t pteval, unsigned int nr)
> +{
> +	if (unlikely(pte_valid_napot(pteval))) {
> +		unsigned int order = ilog2(nr);
> +
> +		if (!is_napot_order(order)) {
> +			/*
> +			 * Something's weird, we are given a NAPOT pte but the

No, nothing is weird.  This can happen under a lot of different
circumstances.  For example, one might mmap() part of a file and the
folio containing the data is only partially mapped.  The filesystem /
page cache might choose to use a folio order that isn't one of your
magic hardware orders.

> +			 * size of the mapping is not a known NAPOT mapping
> +			 * size, so clear the NAPOT bit and map this without
> +			 * NAPOT support: core mm only manipulates pte with the
> +			 * real pfn so we know the pte is valid without the N
> +			 * bit.
> +			 */
> +			pr_err("Incorrect NAPOT mapping, resetting.\n");
> +			pteval = pte_clear_napot(pteval);
> +		} else {
> +			/*
> +			 * NAPOT ptes that arrive here only have the N bit set
> +			 * and their pfn does not contain the mapping size, so
> +			 * set that here.
> +			 */
> +			pteval = pte_mknapot(pteval, order);

You're assuming that pteval is aligned to the order that you've
calculated, and again that's not true.  For example, the user may have
called mmap() on range 0x21000-0x40000 of a file which is covered by
a 128kB folio.  You'll be called with a pteval pointing to 0x21000 and
calculate that you can put a 64kB entry there ... no.

I'd suggest you do some testing with fstests and xfs as your underlying
filesystem.  It should catch these kinds of mistakes.