[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v13 0/5] UFFD write-tracking migration/snapshots

From: David Hildenbrand
Subject: Re: [PATCH v13 0/5] UFFD write-tracking migration/snapshots
Date: Sat, 13 Feb 2021 11:30:13 +0100

> Am 13.02.2021 um 10:34 schrieb Andrey Gruzdev <andrey.gruzdev@virtuozzo.com>:
>> 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?
>> 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.
I tried to explain how your implementation breaks *the guest inside the 
snapshot* (I have no idea why you talk about sensitive information). If you run 
the snapshot, the guest will run into trouble, because the snapshot contains 
different data than the guest expects:

1. with discards before snapshotting started and free page reporting is running
2. with discards after snapshotting started

Maybe Peter can enlighten you, or the links I shared.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]