linux-kernel - Re: [PATCH v4] virt: vmgenid: introduce driver for reinitializing RNG on VM fork

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:   Fri, 25 Feb 2022 16:31:02 +0100
From:   Alexander Graf <graf@...zon.com>
To:     Greg KH <gregkh@...uxfoundation.org>
CC:     "Jason A. Donenfeld" <Jason@...c4.com>, <kvm@...r.kernel.org>,
        <linux-crypto@...r.kernel.org>, <linux-hyperv@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <adrian@...ity.io>,
        <ardb@...nel.org>, <ben@...portsystems.com>, <berrange@...hat.com>,
        <colmmacc@...zon.com>, <decui@...rosoft.com>, <dwmw@...zon.co.uk>,
        <ebiggers@...nel.org>, <ehabkost@...hat.com>,
        <haiyangz@...rosoft.com>, <imammedo@...hat.com>,
        <jannh@...gle.com>, <kys@...rosoft.com>, <lersek@...hat.com>,
        <linux@...inikbrodowski.net>, <mst@...hat.com>,
        <qemu-devel@...gnu.org>, <raduweis@...zon.com>,
        <sthemmin@...rosoft.com>, <tytso@....edu>, <wei.liu@...nel.org>
Subject: Re: [PATCH v4] virt: vmgenid: introduce driver for reinitializing RNG
 on VM fork

On 25.02.22 15:36, Greg KH wrote:
> On Fri, Feb 25, 2022 at 02:57:38PM +0100, Alexander Graf wrote:
>>> +
>>> +       phys_addr = (obj->package.elements[0].integer.value << 0) |
>>> +                   (obj->package.elements[1].integer.value << 32);
>>> +       state->next_id = devm_memremap(&device->dev, phys_addr, VMGENID_SIZE, MEMREMAP_WB);
>>> +       if (!state->next_id) {
>>> +               ret = -ENOMEM;
>>> +               goto out;
>>> +       }
>>> +
>>> +       memcpy(state->this_id, state->next_id, sizeof(state->this_id));
>>> +       add_device_randomness(state->this_id, sizeof(state->this_id));
>>
>> Please expose the vmgenid via /sysfs so that user space even remotely has a
>> chance to check if it's been cloned.
> Export it how?  And why, who would care?

You can just create a sysfs file that contains it. The same way we have 
sysfs files for UEFI config tables. Or sysfs files for the acpi device 
nodes themselves.

I personally don't care if we put this into a generic location 
(/sys/hypervisor for example) or into the existing acpi device node as 
additional file you can just read.

Who would care? Well, for starters I would care for debugging purposes 
:). Extracting the ID and validating that it's different than before is 
quite useful when you want to check if the clone rng adjustment actually 
worked.

I don't have very strong feelings on it though - unlike the _CID 
conversation.

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