Re: [PATCH] mm/hmm: reject shadow-stack mappings

[David Hildenbrand (Arm)]

On 11/14/26 08:25, Gregory Price (Meta) wrote:
> On 2026-11-13 20:20 -0400, Jason Gunthorpe wrote:
>> On Fri, Nov 13, 2026 at 03:41:33PM -0500, Gregory Price (Meta) wrote:
>>>
>>> Some of the context is here:
>>> https://lore.kernel.org/all/20261111-mason-migrate-et-al-fixes-v1-10-3d2454362e8d@xxxxxxxxxx/
>>>
>>> We had a similar issue with migration, but this should handle the DMA
>>> case as well.
>>>
>>> It's "technically writable" but the kernel is supposed to prevent that.
>>
>> Bah, it's not writable at all. The CPU PTE has write disabled and
>> someone thought it was a good idea to make pte_write() return true
>> because the CPU allows writes through a special instruction on this
>> special PTE? So now all the places like this think its writable, when
>> it really isn't.
>>
> 
> I completely missed this, that will teach me to trust pte_write() I
> guess... what a bizarre design choice.  I'm sure there's "reasons".
> 
>> You could also fix this by having something like pte_real_write() or
>> whatever that doesn't lie about the write bit in the PTE :|
>>
> 
> or rename pte_write() to pte_fake_write() instead and restore
> pte_write() to its former truthful glory

It's writable by the hardware, that's what matters to core-mm, for example, when
it comes to things like fork(), mproetect() etc.

*nobody* besides selected core-mm code should ever write to random PTEs. They
shouldn't ever even care about pte_write().

We have GUP for that, which takes care of that oddity properly when deciding
whether we can *actually* write to a mapped page.

Well, and we have HMM that reimplements part of GUP in ugly ways (sorry) that we
missed.

-- 
Cheers,

David