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: <87jz1obyd7.fsf@oracle.com>
Date: Tue, 23 Sep 2025 15:25:08 -0700
From: Ankur Arora <ankur.a.arora@...cle.com>
To: David Hildenbrand <david@...hat.com>
Cc: Ankur Arora <ankur.a.arora@...cle.com>, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org, x86@...nel.org, akpm@...ux-foundation.org,
        bp@...en8.de, dave.hansen@...ux.intel.com, hpa@...or.com,
        mingo@...hat.com, mjguzik@...il.com, luto@...nel.org,
        peterz@...radead.org, acme@...nel.org, namhyung@...nel.org,
        tglx@...utronix.de, willy@...radead.org, raghavendra.kt@....com,
        boris.ostrovsky@...cle.com, konrad.wilk@...cle.com
Subject: Re: [PATCH v7 12/16] arm: mm: define clear_user_highpages()


David Hildenbrand <david@...hat.com> writes:

> On 17.09.25 17:24, Ankur Arora wrote:
>> For configurations with CONFIG_MMU we do not define clear_user_page().
>> This runs into issues for configurations with !CONFIG_HIGHMEM, because
>> clear_user_highpages() expects to clear_user_page() (via a default
>> version of clear_user_pages()).
>
> I'm confused. Can you elaborate once more why we cannot take care of that in
> common code?

So my definition of clear_user_highpages,

    +#ifndef clear_user_highpages
    +static inline void clear_user_highpages(struct page *page, unsigned long vaddr,
    +					unsigned int npages)
    +{
    +	if (!IS_ENABLED(CONFIG_HIGHMEM)) {
    +		void *base = page_address(page);
    +		clear_user_pages(base, vaddr, page, npages);
    +		return;
    +	}
    +
    +	do {
    +		clear_user_highpage(page, vaddr);
    +		vaddr += PAGE_SIZE;
    +		page++;
    +	} while (--npages);
    +}
    +#endif

assumes one of the following:

  1. clear_user_highpages is defined by the architecture or,
  2. HIGHMEM => arch defines clear_user_highpage or clear_user_page
  3. !HIGHMEM => arch defines clear_user_pages or clear_user_page

Case 2 is fine, since ARM has clear_user_highpage().

Case 3 runs into a problem since ARM doesn't have clear_user_pages()
or clear_user_page() (it does have the second, but only with !CONFIG_MMU).

> If it's about clear_user_pages(), then you can just switch from
> !IS_ENABLED(CONFIG_HIGHMEM) to ifdef in patch #11.

It's worse than just clear_user_pages(), since we will have
clear_user_pages() (due to the defintion in patch-10) but that
is broken since the arch doesn't define clear_user_page().

I think the fallback defintions of clear_user_highpages() and
clear_user_pages() are reasonably sane so this needs to be addressed
in the arch code.

I defined clear_user_highpages() since it already has clear_user_highpage().

Another solution might be to define clear_user_page() for ARM which
would also address the broken-ness of clear_user_pages() but that
is more intrusive since that needs actual knowledge of the ARM mapping
model(s).

--
ankur

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ