From: Alexander Graf <graf@amazon.com>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: <kvm@vger.kernel.org>, <linux-crypto@vger.kernel.org>,
<linux-hyperv@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<adrian@parity.io>, <ardb@kernel.org>, <ben@skyportsystems.com>,
<berrange@redhat.com>, <colmmacc@amazon.com>,
<decui@microsoft.com>, <dwmw@amazon.co.uk>, <ebiggers@kernel.org>,
<ehabkost@redhat.com>, <gregkh@linuxfoundation.org>,
<haiyangz@microsoft.com>, <imammedo@redhat.com>,
<jannh@google.com>, <kys@microsoft.com>, <lersek@redhat.com>,
<linux@dominikbrodowski.net>, <mst@redhat.com>,
<qemu-devel@nongnu.org>, <raduweis@amazon.com>,
<sthemmin@microsoft.com>, <tytso@mit.edu>, <wei.liu@kernel.org>
Subject: Re: [PATCH v4] virt: vmgenid: introduce driver for reinitializing RNG on VM fork
Date: Fri, 25 Feb 2022 15:18:43 +0100 [thread overview]
Message-ID: <88ebdc32-2e94-ef28-37ed-1c927c12af43@amazon.com> (raw)
In-Reply-To: <YhjjuMOeV7+T7thS@zx2c4.com>
On 25.02.22 15:12, Jason A. Donenfeld wrote:
> Hi Alex,
>
> On Fri, Feb 25, 2022 at 02:57:38PM +0100, Alexander Graf wrote:
>>> +static const struct acpi_device_id vmgenid_ids[] = {
>>> + { "VMGENID", 0 },
>>> + { "QEMUVGID", 0 },
>>
>> According to the VMGenID spec[1], you can only rely on _CID and _DDN for
>> matching. They both contain "VM_Gen_Counter". The list above contains
>> _HID values which are not an official identifier for the VMGenID device.
>>
>> IIRC the ACPI device match logic does match _CID in addition to _HID.
>> However, it is limited to 8 characters. Let me paste an experimental
>> hack I did back then to do the _CID matching instead.
>>
>> [1]
>> https://download.microsoft.com/download/3/1/C/31CFC307-98CA-4CA5-914C-D9772691E214/VirtualMachineGenerationID.docx
>>
>>
>> Alex
>>
>> diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
>> index 1682f8b454a2..452443d79d87 100644
>> --- a/drivers/acpi/bus.c
>> +++ b/drivers/acpi/bus.c
>> @@ -748,7 +748,7 @@ static bool __acpi_match_device(struct acpi_device
>> *device,
>> /* First, check the ACPI/PNP IDs provided by the caller. */
>> if (acpi_ids) {
>> for (id = acpi_ids; id->id[0] || id->cls; id++) {
>> - if (id->id[0] && !strcmp((char *)id->id, hwid->id))
>> + if (id->id[0] && !strncmp((char *)id->id, hwid->id,
>> ACPI_ID_LEN - 1))
>> goto out_acpi_match;
>> if (id->cls && __acpi_match_device_cls(id, hwid))
>> goto out_acpi_match;
>> diff --git a/drivers/virt/vmgenid.c b/drivers/virt/vmgenid.c
>> index 75a787da8aad..0bfa422cf094 100644
>> --- a/drivers/virt/vmgenid.c
>> +++ b/drivers/virt/vmgenid.c
>> @@ -356,7 +356,8 @@ static void vmgenid_acpi_notify(struct acpi_device
>> *device, u32 event)
>> }
>>
>> static const struct acpi_device_id vmgenid_ids[] = {
>> - {"QEMUVGID", 0},
>> + /* This really is VM_Gen_Counter, but we can only match 8 characters */
>> + {"VM_GEN_C", 0},
>> {"", 0},
>> };
> I recall this part of the old thread. From what I understood, using
> "VMGENID" + "QEMUVGID" worked /well enough/, even if that wasn't
> technically in-spec. Ard noted that relying on _CID like that is
> technically an ACPI spec notification. So we're between one spec and
> another, basically, and doing "VMGENID" + "QEMUVGID" requires fewer
> changes, as mentioned, appears to work fine in my testing.
>
> However, with that said, I think supporting this via "VM_Gen_Counter"
> would be a better eventual thing to do, but will require acks and
> changes from the ACPI maintainers. Do you think you could prepare your
> patch proposal above as something on-top of my tree [1]? And if you can
> convince the ACPI maintainers that that's okay, then I'll happily take
> the patch.
Sure, let me send the ACPI patch stand alone. No need to include the
VMGenID change in there.
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
next prev parent reply other threads:[~2022-02-25 14:19 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-24 13:39 [PATCH v3 0/2] VM fork detection for RNG Jason A. Donenfeld
2022-02-24 13:39 ` [PATCH v3 1/2] random: add mechanism for VM forks to reinitialize crng Jason A. Donenfeld
2022-02-25 11:26 ` Ard Biesheuvel
2022-02-25 11:43 ` Jason A. Donenfeld
2022-02-25 11:44 ` Ard Biesheuvel
2022-02-24 13:39 ` [PATCH v3 2/2] virt: vmgenid: introduce driver for reinitializing RNG on VM fork Jason A. Donenfeld
2022-02-25 10:37 ` Laszlo Ersek
2022-02-25 11:24 ` Ard Biesheuvel
2022-02-25 11:51 ` Michael S. Tsirkin
2022-02-25 12:01 ` Jason A. Donenfeld
2022-02-25 12:00 ` Jason A. Donenfeld
2022-02-25 12:48 ` [PATCH v4] " Jason A. Donenfeld
2022-02-25 12:52 ` Greg KH
2022-02-25 12:53 ` Greg KH
2022-02-25 12:56 ` Jason A. Donenfeld
2022-02-25 15:04 ` Ard Biesheuvel
2022-02-25 13:57 ` Alexander Graf
2022-02-25 14:12 ` Jason A. Donenfeld
2022-02-25 14:18 ` Jason A. Donenfeld
2022-02-25 14:18 ` Alexander Graf [this message]
2022-02-25 14:33 ` Jason A. Donenfeld
2022-02-25 15:11 ` Alexander Graf
2022-02-25 15:16 ` Ard Biesheuvel
2022-02-25 15:22 ` Alexander Graf
2022-02-25 15:43 ` Jason A. Donenfeld
2022-02-25 15:57 ` Alexander Graf
2022-02-25 15:34 ` Jason A. Donenfeld
2022-02-25 15:37 ` Alexander Graf
2022-02-25 15:45 ` Jason A. Donenfeld
2022-02-25 14:36 ` Greg KH
2022-02-25 15:31 ` Alexander Graf
2022-02-25 15:36 ` Jason A. Donenfeld
2022-02-25 14:54 ` Jason A. Donenfeld
2022-02-25 15:15 ` Alexander Graf
2022-02-25 15:28 ` Jason A. Donenfeld
2022-02-25 15:03 ` Ard Biesheuvel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=88ebdc32-2e94-ef28-37ed-1c927c12af43@amazon.com \
--to=graf@amazon.com \
--cc=Jason@zx2c4.com \
--cc=adrian@parity.io \
--cc=ardb@kernel.org \
--cc=ben@skyportsystems.com \
--cc=berrange@redhat.com \
--cc=colmmacc@amazon.com \
--cc=decui@microsoft.com \
--cc=dwmw@amazon.co.uk \
--cc=ebiggers@kernel.org \
--cc=ehabkost@redhat.com \
--cc=gregkh@linuxfoundation.org \
--cc=haiyangz@microsoft.com \
--cc=imammedo@redhat.com \
--cc=jannh@google.com \
--cc=kvm@vger.kernel.org \
--cc=kys@microsoft.com \
--cc=lersek@redhat.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@dominikbrodowski.net \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=raduweis@amazon.com \
--cc=sthemmin@microsoft.com \
--cc=tytso@mit.edu \
--cc=wei.liu@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox