On 09.02.2021 22:06, David Hildenbrand wrote:
Hi,
just stumbled over this, quick question:
I recently played with UFFD_WP and notices that write protection is
only effective on pages/ranges that have already pages populated (IOW:
!pte_none() in the kernel).
In case memory was never populated (or was discarded using e.g.,
madvice(DONTNEED)), write-protection will be skipped silently and you
won't get WP events for applicable pages.
So if someone writes to a yet unpoupulated page ("zero"), you won't
get WP events.
I can spot that you do a single uffd_change_protection() on the whole
RAMBlock.
How are you handling that scenario, or why don't you have to handle
that scenario?
Hi David,
I really wonder if such a problem exists.. If we are talking about a
I immediately ran into this issue with my simplest test cases. :)
write to an unpopulated page, we should get first page fault on
non-present page and populate it with protection bits from respective
vma.
For UFFD_WP vma's page will be populated non-writable. So we'll get
another page fault on present but read-only page and go to
handle_userfault.
See the attached test program. Triggers for me on 5.11.0-rc6+ and
5.9.13-200.fc33
gcc -lpthread uffdio_wp.c -o uffdio_wp
./uffdio_wp
WP did not fire
Uncomment the placement of the zeropage just before registering to
make the WP actually trigger. If there is no PTE, there is nothing to
protect.
And it makes sense: How should the fault handler know which ranges you
wp-ed, if there is no place to store that information (the PTEs!). The
VMA cannot tell that story, it only knows that someone registered
UFFD_WP to selectively wp some parts.
You might have to register also for MISSING faults and place zero pages.
Looked at the kernel code, agree that we miss WP events for unpopulated
pages, UFFD_WP softbit won't be set in this case. But it doesn't make
saved snapshot inconsistent or introduce security issues. The only side
effect is that we may save updated page instead of zeroed, just
increasing snapshot size. However this guest-physical page has never
been touched from the point of view of saved vCPU/device state and is
not a concern.
Often (at least on desktop Windows guests) only a small part of RAM has
ever been allocated by guest. Migration code needs to read each
guest-physical page, so we'll have a lot of additional UFFD events, much
more MISSING events then WP-faults.
And the main problem is that adding MISSING handler is impossible in
current single-threaded snapshot code. We'll get an immediate deadlock
on iterative page read.
--
Andrey Gruzdev, Principal Engineer
Virtuozzo GmbH +7-903-247-6397
virtuzzo.com
