linux-kernel - Re: [RFC PATCH 0/4] KVM: x86/mmu: Rework marking folios dirty/accessed

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]

Date: Thu, 4 Apr 2024 20:23:43 +0200
From: David Hildenbrand <david@...hat.com>
To: Sean Christopherson <seanjc@...gle.com>
Cc: David Matlack <dmatlack@...gle.com>, Paolo Bonzini <pbonzini@...hat.com>,
 kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
 David Stevens <stevensd@...omium.org>, Matthew Wilcox <willy@...radead.org>
Subject: Re: [RFC PATCH 0/4] KVM: x86/mmu: Rework marking folios
 dirty/accessed

On 04.04.24 19:31, Sean Christopherson wrote:
> On Thu, Apr 04, 2024, David Hildenbrand wrote:
>> On 04.04.24 00:19, Sean Christopherson wrote:
>>> Hmm, we essentially already have an mmu_notifier today, since secondary MMUs need
>>> to be invalidated before consuming dirty status.  Isn't the end result essentially
>>> a sane FOLL_TOUCH?
>>
>> Likely. As stated in my first mail, FOLL_TOUCH is a bit of a mess right now.
>>
>> Having something that makes sure the writable PTE/PMD is dirty (or
>> alternatively sets it dirty), paired with MMU notifiers notifying on any
>> mkclean would be one option that would leave handling how to handle dirtying
>> of folios completely to the core. It would behave just like a CPU writing to
>> the page table, which would set the pte dirty.
>>
>> Of course, if frequent clearing of the dirty PTE/PMD bit would be a problem
>> (like we discussed for the accessed bit), that would not be an option. But
>> from what I recall, only clearing the PTE/PMD dirty bit is rather rare.
> 
> And AFAICT, all cases already invalidate secondary MMUs anyways, so if anything
> it would probably be a net positive, e.g. the notification could more precisely
> say that SPTEs need to be read-only, not blasted away completely.
> 

As discussed, I think at least madvise_free_pte_range() wouldn't do 
that. Notifiers would only get called later when actually zapping the 
folio. So at least for some time, you would have the PTE not dirty, but 
the SPTE writable or even dirty. So you'd have to set the page dirty 
when zapping the SPTE ... and IMHO that is what we should maybe try to 
avoid :)

-- 
Cheers,

David / dhildenb