linux-kernel - Re: [QUESTION] Plain dereference and READ

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <8477d9ec-b9ce-4a3d-b61f-1bd44d3360a5@redhat.com>
Date: Wed, 5 Mar 2025 11:46:41 +0100
From: David Hildenbrand <david@...hat.com>
To: Dev Jain <dev.jain@....com>, willy@...radead.org, ziy@...dia.com,
 hughd@...gle.com, ryan.roberts@....com, linux-kernel@...r.kernel.org,
 linux-mm@...ck.org
Subject: Re: [QUESTION] Plain dereference and READ_ONCE() in fault handler

On 05.03.25 11:21, Dev Jain wrote:
> In __handle_mm_fault(),
> 
> 1. Why is there a barrier() for the PUD logic?

Good question. It was added in

commit a00cc7d9dd93d66a3fb83fc52aa57a4bec51c517
Author: Matthew Wilcox <willy@...radead.org>
Date:   Fri Feb 24 14:57:02 2017 -0800

     mm, x86: add support for PUD-sized transparent hugepages

Maybe it was an alternative to performing a READ_ONCE(*vmf.pud).

Maybe it was done that way, because pudp_get_lockless() does not exist. 
And it would likely not be required, because on architectures where 
ptep_get_lockless() does some magic (see below, mostly 32bit), PUD THP 
are not applicable.

> 2. For the PMD logic, in the if block, we use *vmf.pmd, and in the else block
>     we use pmdp_get_lockless(); what if someone changes the pmd just when we
>     have begun processing the conditions in the if block, fail in the if block
>     and then the else block operates on a different pmd value. Shouldn't we cache
>     the value of the pmd and operate on a single consistent value until we take the
>     lock and then finally check using pxd_same() and friends?

The pmd_none(*vmf.pmd) is fine. create_huge_pmd() must be able to deal 
with races, because we are not holding any locks.

We only have to use pmdp_get_lockless() when we want to effectively 
perform a READ_ONCE(), and make sure that we read something "reasonable" 
that we can operate on, even with concurrent changes. (e.g., not read a 
garbage PFN just because of some concurrent changes)

We'll store the value in vmf.orig_pmd, on which we'll operate and try to 
detect later changes using pmd_same(). So we really want something 
consistent in there.

See the description above ptep_get_lockless(), why we cannot simply do a 
READ_ONCE on architectures where a PTE cannot be read atomically (e.g., 
8 byte PTEs on 32bit architecture).

-- 
Cheers,

David / dhildenb