On 17.02.21 00:35, Peter Xu wrote:
Hi, Andrey,
On Sat, Feb 13, 2021 at 12:34:07PM +0300, Andrey Gruzdev wrote:
On 12.02.2021 19:11, Peter Xu wrote:
On Fri, Feb 12, 2021 at 09:52:52AM +0100, David Hildenbrand wrote:
On 12.02.21 04:06, Peter Xu wrote:
On Thu, Feb 11, 2021 at 10:09:58PM +0100, David Hildenbrand wrote:
The issue is when the discard happened before starting the snapshot.
Write-protection won‘t work and the zeroed content won‘t be retained in the
snapshot.
I see what you mean now, and iiuc it will only be a problem if init_on_free=1.
I think CONFIG_INIT_ON_FREE_DEFAULT_ON should be off for most distros, so the
Yes, some distros seem to enable init_on_alloc instead. Looking at the
introducing commit 6471384af2a6 ("mm: security: introduce init_on_alloc=1
and init_on_free=1 boot options") there are security use cases and it might
become important with memory tagging.
Note that in Linux, there was also the option to poison pages with 0,
removed via f289041ed4cf ("mm, page_poison: remove
CONFIG_PAGE_POISONING_ZERO"), available in some kernels that supported free
page reporting.
It got removed and use cases got told to use init_on_free.
I think we talk about init_on_free()/init_on_alloc() on guest side, right?
Right. IIUC it's the init_on_free() that matters.
We'll have no issue if init_on_alloc=1 && init_on_free=0, since in that case
all pages will be zeroed after all before the new page returned to the caller
to allocate the page. Then we're safe, I think.
Still can't get how it relates to host's unpopulated pages..
Try to look from hardware side. Untouched SDRAM in hardware is required to
contain zeroes somehow? No.
These 'trash' pages in migration stream are like never written physical memory
pages, they are really
not needed in snapshot but they don't do any harm as well as there's no harm in
that never-written physical
page is full of garbage.
Do these 'trash' pages in snapshot contain sensitive information not allowed to
be accessed by the same VM?
I think no. Or we need a good example how it can be potentially exploited.
The only issue that I see is madvise(MADV_DONTNEED) for RAM blocks during
snapshotting. And free page reporting
or memory balloon is secondary - the point is that UFFD_WP snapshot is
incompatible with madvise(MADV_DONTNEED) on
hypervisor side. No matter which guest functionality can induce it.
I think the problem is if with init_on_free=1, the kernel will assume that
all the pages that got freed has been zeroed before-hand so it thinks that it's
a waste of time to zero it again when the page is reused/reallocated. As a
reference see kernel prep_new_page() where there's:
if (!free_pages_prezeroed() && want_init_on_alloc(gfp_flags))
kernel_init_free_pages(page, 1 << order);
In this case I believe free_pages_prezeroed() will return true, then we don't
even need to check want_init_on_alloc() at all. Note that it'll cover all the
cases where kernel allocates with __GFP_ZERO: it means it could happen that
even the guest kernel tries to alloc_page(__GFP_ZERO) it may got a page with
random data after the live snapshot is loaded. So it's not about any hardware,
it's the optimization of guest kernel instead. It is actually reasonable and
efficient since if we *know* that page is zero page then we shouldn't bother
zeroing it again. However it brought us a bit of trouble on live snapshot that
the current solution might not work for all guest OS configurations.
Adding to that, we are so far talking about how Linux *currently*
implements it, but that is just an instance of the problem where it
could happen in practice.
Free page reporting documents in the spec that with the right
configuration, previously reported free pages are guaranteed to retain a
certain value (e.g., 0) when re-accessed. So any future guest changes
that rely on the virtio spec (e.g., Windows support) would be
problematic - as these pages in the snapshot don't actually keep the value.
--
Thanks,
David / dhildenb
