Re: [PATCH 0/2] virt: vmgenid: add generation counter

From: bchalios
Date: Wed Aug 10 2022 - 05:20:41 EST


Hi Jason

On 8/4/22 4:59 PM, "Jason A. Donenfeld" <Jason@xxxxxxxxx> wrote:
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



Hi Babis,

On Wed, Aug 03, 2022 at 05:21:25PM +0200, bchalios@xxxxxxxxx wrote:
> From: Babis Chalios <bchalios@xxxxxxxxx>
>
> Linux recently added support for the VM Generation ID mechanism from
> Microsoft. The way this works currently is using the 128-bit blob
> provided by the vmgenid device to re-seed the RNG. While this works it
> has two main issues, (a) it is inherently racy due to the fact that it
> relies on a ACPI notification being delivered and handled and (b) the ID
> is unsuitable for exposing to user-space.
>
> This patch-set extends the vmgenid device to introduce a generation
> counter, a 32-bit counter which is different every time the unique ID
> changes. The addition to the original implementation in QEMU can be
> found here:
> https://lists.nongnu.org/archive/html/qemu-devel/2022-08/msg00524.html.
>
> The first patch re-works slightly the current vmgenid driver to add a
> function that parses an object from the vmgenid device and returns the
> physical address of the vmgenid data. The second patch uses that
> function to parse additionally the address of the generation counter
> from the vmgenid namespace. The counter is then exposed to the
> user-space through a misc-device which provides `read` and `mmap`
> interfaces.

First, with regards to your mmap interface, it's more likely that this
kind of thing will be eventually folded into my investigations regarding
the RNG and the vDSO (which would make this kind of thing accessible
without needing the file system).

Regarding the counter itself, I don't want to rush into augmenting the
vmgenid mechanism until we've had some conversations with Microsoft. But
also, it seems like you might have missed the extensive previous
discussion about this. There was some tradeoff in efficiency about
mapping this all the way through, as doing so would require the counter
to be in a totally separate page as the main 128-bit ID, versus just
having the kernel manage a separate counter and incur a potential [maybe
acceptable? unclear] race.

Jason


Just linking here a comment from Michael on the QEMU discussion: https://www.mail-archive.com/qemu-devel@xxxxxxxxxx/msg903695.html

Cheers,
Babis


Amazon Spain Services sociedad limitada unipersonal, Calle Ramirez de Prado 5, 28045 Madrid. Registro Mercantil de Madrid . Tomo 22458 . Folio 102 . Hoja M-401234 . CIF B84570936