From: Babis Chalios <bchalios@amazon.es>

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.

Babis Chalios (2):
  virt: vmgenid: add helper function to parse ADDR
  virt: vmgenid: add support for generation counter

 Documentation/virt/vmgenid.rst | 120 ++++++++++++++++++++++++++
 drivers/virt/vmgenid.c         | 151 ++++++++++++++++++++++++++++-----
 2 files changed, 251 insertions(+), 20 deletions(-)
 create mode 100644 Documentation/virt/vmgenid.rst

-- 
2.37.1

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

Hi Babis,

On Wed, Aug 03, 2022 at 05:21:25PM +0200, bchalios@amazon.es wrote:
> From: Babis Chalios <bchalios@amazon.es>
> 
> 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

Hi Jason

On 8/4/22 4:59 PM, "Jason A. Donenfeld" <Jason@zx2c4.com> 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@amazon.es wrote:
> > From: Babis Chalios <bchalios@amazon.es>
> >
> > 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@nongnu.org/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

Hi Jason,

On 8/4/22 4:59 PM, "Jason A. Donenfeld" <Jason@zx2c4.com> 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@amazon.es wrote:
> > From: Babis Chalios <bchalios@amazon.es>
> >
> > 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).
> 

Interesting, could you share a link to discussions / code regarding this?


> 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.
> 

Again, would you have pointers to this discussion? I have been following this
thread: https://lkml.org/lkml/2022/3/1/693. I am interested on the take that
the race would be acceptable.

> Jason
>

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

On 3/8/22 17:21, bchalios@amazon.es wrote:
> From: Babis Chalios <bchalios@amazon.es>
>
> 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.
>
> Babis Chalios (2):
>    virt: vmgenid: add helper function to parse ADDR
>    virt: vmgenid: add support for generation counter
>
>   Documentation/virt/vmgenid.rst | 120 ++++++++++++++++++++++++++
>   drivers/virt/vmgenid.c         | 151 ++++++++++++++++++++++++++++-----
>   2 files changed, 251 insertions(+), 20 deletions(-)
>   create mode 100644 Documentation/virt/vmgenid.rst
>

I am also CCing Michael from Microsoft since he was involved in the
last discussions regarding the Linux driver.

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

(Correctly) CC'ing more people in the discussion. Apologies for this.

On 3/8/22 17:21, bchalios@amazon.es wrote:
> From: Babis Chalios <bchalios@amazon.es>
>
> 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.
>
> Babis Chalios (2):
>    virt: vmgenid: add helper function to parse ADDR
>    virt: vmgenid: add support for generation counter
>
>   Documentation/virt/vmgenid.rst | 120 ++++++++++++++++++++++++++
>   drivers/virt/vmgenid.c         | 151 ++++++++++++++++++++++++++++-----
>   2 files changed, 251 insertions(+), 20 deletions(-)
>   create mode 100644 Documentation/virt/vmgenid.rst
>

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