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

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

 




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






[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]

  Powered by Linux