All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Alexander Graf <graf@amazon.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:12:08 +0100	[thread overview]
Message-ID: <YhjjuMOeV7+T7thS@zx2c4.com> (raw)
In-Reply-To: <05c9f2a9-accb-e0de-aac7-b212adac7eb2@amazon.com>

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.

Jason

[1] https://git.kernel.org/pub/scm/linux/kernel/git/crng/random.git/

WARNING: multiple messages have this Message-ID (diff)
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Alexander Graf <graf@amazon.com>
Cc: linux-hyperv@vger.kernel.org, kvm@vger.kernel.org,
	mst@redhat.com, raduweis@amazon.com, qemu-devel@nongnu.org,
	linux@dominikbrodowski.net, kys@microsoft.com, ardb@kernel.org,
	wei.liu@kernel.org, sthemmin@microsoft.com,
	ben@skyportsystems.com, decui@microsoft.com, ebiggers@kernel.org,
	lersek@redhat.com, ehabkost@redhat.com, adrian@parity.io,
	jannh@google.com, haiyangz@microsoft.com, tytso@mit.edu,
	colmmacc@amazon.com, berrange@redhat.com,
	gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org,
	linux-crypto@vger.kernel.org, imammedo@redhat.com,
	dwmw@amazon.co.uk
Subject: Re: [PATCH v4] virt: vmgenid: introduce driver for reinitializing RNG on VM fork
Date: Fri, 25 Feb 2022 15:12:08 +0100	[thread overview]
Message-ID: <YhjjuMOeV7+T7thS@zx2c4.com> (raw)
In-Reply-To: <05c9f2a9-accb-e0de-aac7-b212adac7eb2@amazon.com>

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.

Jason

[1] https://git.kernel.org/pub/scm/linux/kernel/git/crng/random.git/


  reply	other threads:[~2022-02-25 14:12 UTC|newest]

Thread overview: 65+ 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 ` 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-24 13:39   ` Jason A. Donenfeld
2022-02-25 11:26   ` Ard Biesheuvel
2022-02-25 11:26     ` Ard Biesheuvel
2022-02-25 11:43     ` Jason A. Donenfeld
2022-02-25 11:43       ` Jason A. Donenfeld
2022-02-25 11:44       ` Ard Biesheuvel
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-24 13:39   ` Jason A. Donenfeld
2022-02-25 10:37   ` Laszlo Ersek
2022-02-25 10:37     ` Laszlo Ersek
2022-02-25 11:24   ` Ard Biesheuvel
2022-02-25 11:24     ` Ard Biesheuvel
2022-02-25 11:51     ` Michael S. Tsirkin
2022-02-25 11:51       ` Michael S. Tsirkin
2022-02-25 12:01       ` Jason A. Donenfeld
2022-02-25 12:01         ` Jason A. Donenfeld
2022-02-25 12:00     ` 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:48         ` Jason A. Donenfeld
2022-02-25 12:52         ` Greg KH
2022-02-25 12:52           ` Greg KH
2022-02-25 12:53         ` Greg KH
2022-02-25 12:53           ` Greg KH
2022-02-25 12:56           ` Jason A. Donenfeld
2022-02-25 12:56             ` Jason A. Donenfeld
2022-02-25 15:04           ` Ard Biesheuvel
2022-02-25 15:04             ` Ard Biesheuvel
2022-02-25 13:57         ` Alexander Graf
2022-02-25 14:12           ` Jason A. Donenfeld [this message]
2022-02-25 14:12             ` Jason A. Donenfeld
2022-02-25 14:18             ` Jason A. Donenfeld
2022-02-25 14:18               ` Jason A. Donenfeld
2022-02-25 14:18             ` Alexander Graf
2022-02-25 14:33               ` Jason A. Donenfeld
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:16                     ` Ard Biesheuvel
2022-02-25 15:22                     ` Alexander Graf
2022-02-25 15:43                       ` Jason A. Donenfeld
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:34                       ` Jason A. Donenfeld
2022-02-25 15:37                       ` Alexander Graf
2022-02-25 15:45                         ` Jason A. Donenfeld
2022-02-25 15:45                           ` Jason A. Donenfeld
2022-02-25 14:36           ` Greg KH
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 15:36                 ` Jason A. Donenfeld
2022-02-25 14:54           ` 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:28                 ` Jason A. Donenfeld
2022-02-25 15:03           ` Ard Biesheuvel
2022-02-25 15:03             ` Ard Biesheuvel
2022-02-25 15:14             ` Alexander Graf

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=YhjjuMOeV7+T7thS@zx2c4.com \
    --to=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=graf@amazon.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.