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

[Alexander Graf <graf@amazon.com>]

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