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