|
From: | Alexander Graf |
Subject: | Re: [PATCH v4] virt: vmgenid: introduce driver for reinitializing RNG on VM fork |
Date: | Fri, 25 Feb 2022 16:31:02 +0100 |
User-agent: | Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |