linux-kernel - Re: [PATCH] drivers/virt: vmgenid: add vm generation id driver

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]

Message-ID: <b2f8ecec-35e8-93c6-b4cb-bb89ee8baa2d@amazon.de>
Date:   Tue, 20 Oct 2020 11:54:56 +0200
From:   Alexander Graf <graf@...zon.de>
To:     Christian Borntraeger <borntraeger@...ibm.com>,
        "Jason A. Donenfeld" <Jason@...c4.com>,
        Jann Horn <jannh@...gle.com>
CC:     Willy Tarreau <w@....eu>, Colm MacCarthaigh <colmmacc@...zon.com>,
        "Catangiu, Adrian Costin" <acatan@...zon.com>,
        Andy Lutomirski <luto@...nel.org>,
        "Theodore Y. Ts'o" <tytso@....edu>,
        Eric Biggers <ebiggers@...nel.org>,
        "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
        kernel list <linux-kernel@...r.kernel.org>,
        "open list:VIRTIO GPU DRIVER" 
        <virtualization@...ts.linux-foundation.org>,
        "Woodhouse, David" <dwmw@...zon.co.uk>, <bonzini@....org>,
        "Singh, Balbir" <sblbir@...zon.com>,
        "Weiss, Radu" <raduweis@...zon.com>, <oridgar@...il.com>,
        <ghammer@...hat.com>, Jonathan Corbet <corbet@....net>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Michael S. Tsirkin" <mst@...hat.com>,
        "Qemu Developers" <qemu-devel@...gnu.org>,
        KVM list <kvm@...r.kernel.org>,
        "Michal Hocko" <mhocko@...nel.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        "Pavel Machek" <pavel@....cz>,
        Linux API <linux-api@...r.kernel.org>, <mpe@...erman.id.au>,
        linux-s390 <linux-s390@...r.kernel.org>
Subject: Re: [PATCH] drivers/virt: vmgenid: add vm generation id driver


On 20.10.20 11:35, Christian Borntraeger wrote:
> On 17.10.20 20:09, Alexander Graf wrote:
>> Hi Jason,
>>
>> On 17.10.20 15:24, Jason A. Donenfeld wrote:
>>>
>>> After discussing this offline with Jann a bit, I have a few general
>>> comments on the design of this.
>>>
>>> First, the UUID communicated by the hypervisor should be consumed by
>>> the kernel -- added as another input to the rng -- and then userspace
>>
>> We definitely want a kernel internal notifier as well, yes :).
>>
>>> should be notified that it should reseed any userspace RNGs that it
>>> may have, without actually communicating that UUID to userspace. IOW,
>>
>> I also tend to agree that it makes sense to disconnect the actual UUID we receive from the notification to user space. This would allow us to create a generic mechanism for VM save/restore cycles across different hypervisors. Let me add PPC and s390x people to the CC list to see whether they have anything remotely similar to the VmGenID mechanism. For x86 and aarch64, the ACPI and memory based VmGenID implemented here is the most obvious option to implement IMHO. It's also already implemented in all major hypervisors.
> 
> Hmm, what we do have configurations (e.g. stfle bits) and we do have a notification mechanism via sclp that notifies guests when things change.
> As of today neither KVM nor Linux implement the sclp change notification mechanism, but I do see value in such a thing.

stfle only stores architected CPU capabilities, no? The UUID is about 
uniquely identifying clones of the same base image, so they can 
reestablish their uniqueness.

That said, your interest means that there may be a mechanism on s390 one 
day, so we should think about making it more generic.

> 
>>
>>> I agree with Jann there. Then, it's the functioning of this
>>> notification mechanism to userspace that is interesting to me.
>>
>> Absolutely! Please have a look at the previous discussion here:
>>
>>
>> https://lore.kernel.org/linux-pm/B7793B7A-3660-4769-9B9A-FFCF250728BB@amazon.com/
>>
>> The user space interface is absolutely what this is about.
> 
> Yes. Passing a notification to userspace is essential. Where I do not see a solution yet is the race between notification and
> already running with the old knowledge.

With a post-mortem interface, we will always have a tiny race window. 
I'm not really convinced that this is a serious problem yet though.

In order to do extract anything off a virtual machine that was cloned, 
you need to communicate with it. If you for example stop the network 
link until all of this device's users have indicated they are finished 
adjusting, the race should be small enough for any practical purposes I 
can think of.


Alex



Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879