Een OEM-licentie naar een Proxmox-VM verhuizen, en wat er mee verhuist

De licentie zit al in de firmware

Genoeg mensen bezitten een licentie voor de Fisher-Price OS (Windows) zonder ooit de productsleutel te hebben gezien. Hij kwam met de machine, en de sleutel woont in de firmware van die machine, in een kleine ACPI-tabel die MSDM heet.

Dan is de machine niet meer de plek waar het werk gebeurt. Of de eigenaar wil die licentie in een VM die hij nu van jou huurt, of de machine zelf wordt gewist, omgebouwd tot Proxmox-host, en het exemplaar van het OS waarmee hij werd geleverd moet terug als VM erbovenop.

Mechanisch is het één QEMU-optie. Dat is het probleem. QEMU geeft elke tabel aan een gast zonder hem te controleren, de gast activeert met welke sleutel hij ook vindt, en nergens in de stack vraagt iets of de licentie dat allemaal toestaat. Deze post behandelt wat de tabel is, hoe je hem in een VM krijgt zonder een corrupte door te geven, wat de voorwaarden van Microsoft zeggen over verhuizen, en waarom een volumelicentie er nooit in de buurt komt.

Wat de tabel is

Sinds OEM Activation 3.0 drukt een pc-bouwer de sleutel niet meer op een sticker aan de onderkant van de kast, waar iedereen met een telefooncamera hem kan kopiëren, en gaat de sleutel in plaats daarvan in de firmware van de machine. De fabrieksgereedschappen van Microsoft “injects the product keys into the firmware”, en de validatiestap controleert “that the MSDM table exists” en dat de header en de velden “comply with the correct formats”¹. Een machine die zo is ingericht, wordt “activated by using the OA3 DPK in the firmware”². MSDM is een gewone ACPI-tabel, en op Linux lees je hem rechtstreeks uit de firmware:

sudo cat /sys/firmware/acpi/tables/MSDM > msdm.bin

De laptop waarop dit geschreven is, heeft er een. 85 bytes.

De gepubliceerde specificatie van Microsoft definieert de standaard ACPI-header van 36 bytes met de signatuur MSDM, en stopt dan. Alles na de header is een “Proprietary data structure that contains all the licensing data necessary to enable Windows activation”³.

QEMU geeft alles door wat je hem geeft

-acpitable file= van QEMU neemt de “whole ACPI table from the specified files, including all ACPI headers (possible overridden by other options)”⁴, en de gast ziet dan een MSDM-tabel precies zoals de firmware van een laptop hem zou presenteren. Dat is gecontroleerd met een bewust nepsleutel. De bytes kwamen er aan de andere kant identiek uit, van signatuur tot laatste teken.

QEMU weigert niets. Dit doet hw/acpi/core.c met een kapotte upload⁵:

De gast kan het verschil niet zien, en jij ook niet totdat iemand een supportticket opent. Het eerste wat iemand ervan hoort, is een klant wiens activering mislukte.

Uploaden klanten deze dus, controleer ze dan voordat QEMU ze ooit ziet:

#!/usr/bin/env python3
"""Refuse anything that is not a well-formed MSDM table before QEMU sees it."""
import re, struct, sys

t = open(sys.argv[1], 'rb').read()
fail = lambda why: sys.exit(f"{sys.argv[1]}: {why}")

if len(t) < 56:                       fail(f"{len(t)} bytes, too short for an MSDM table")
sig, length = t[:4], struct.unpack_from('<I', t, 4)[0]
if sig != b'MSDM':                    fail(f"signature is {sig!r}, not MSDM")
if length != len(t):                  fail(f"header says {length} bytes, file is {len(t)}")
if sum(t) & 0xff:                     fail("checksum does not sum to zero")
ver, _, dtype, _, dlen = struct.unpack_from('<5I', t, 36)
if (ver, dtype) != (1, 1):            fail(f"version {ver}, data type {dtype}: expected 1 and 1")
if dlen != 29 or 56 + dlen != length: fail(f"data length {dlen}: expected 29")
key = t[56:].decode('ascii', 'replace')
if not re.fullmatch(r'([0-9A-Z]{5}-){4}[0-9A-Z]{5}', key): fail("data is not a 5x5 product key")
print(f"OK  OEM {t[10:16].decode(errors='replace').strip()!r}  key *****-*****-*****-*****-{key[-5:]}")

Hij drukt nooit de sleutel af, alleen de laatste groep. Een productsleutel in een logbestand is een productsleutel die iemand anders kan gebruiken.

Gedraaid tegen een goede tabel en drie kapotte kopieën ervan:

OK  OEM 'EXMPLE'  key *****-*****-*****-*****-EEEEE
bad-sum.bin: checksum does not sum to zero
bad-trunc.bin: header says 85 bytes, file is 70
bad-sig.bin: signature is b'SLIC', not MSDM

Waar hij komt, en wie hem daar mag zetten

Een productsleutel is een geheim. Hij hoort nergens waar www-data hem kan lezen, en pmxcfs geeft je precies één plek in /etc/pve waar dat niet kan⁶:

Met 85 bytes zit hij nergens in de buurt van de bestandslimiet van 1 MiB in pmxcfs⁷:

mkdir -p /etc/pve/priv/msdm
check-msdm.py upload.bin && cp upload.bin /etc/pve/priv/msdm/9000.bin
qm set 9000 --args "-acpitable file=/etc/pve/priv/msdm/9000.bin"

qm set --args vervangt de hele regel. Heeft de VM al SMBIOS- of firmwareopties in args, schrijf ze dan allemaal samen uit. En omdat args alleen voor root is, is dit een klus voor je provisioning, niet iets wat een klant vanuit de webinterface kan doen. Zo hoort het ook. De klant levert het bestand, jouw tooling controleert het en koppelt het.

De tabel verhuist een sleutel, geen recht

Hier vraagt de functie om een helder hoofd. De MSDM-tabel naar een VM verhuizen verhuist de sleutel. Niet de licentie.

De eigen voorwaarden van Microsoft zeggen dat, en de regels die ertoe doen passen in een tabel:

De tabel komt altijd van de eigen gelicentieerde machine van de klant, nooit van jouw hosts. Het geval dat recht binnen de tekst valt, is het eenvoudigste: de machine waarmee de licentie werd verkocht, nu met Proxmox erop, met datzelfde exemplaar van de Fisher-Price OS (Windows) verhuisd naar één VM erop. Dat is nog steeds één instantie op één apparaat, en de OEM-voorwaarden staan dat toe “whether that device is physical or virtual”⁸. Een tweede VM, of een andere machine, en dat is het niet meer.

In dat ene geval zijn de machine van de klant en de hypervisor dezelfde doos, dus er valt niets te uploaden en niets te kopiëren. De Proxmox-kernel stelt de MSDM-tabel van de firmware al beschikbaar onder /sys/firmware/acpi/tables/, alleen leesbaar voor root, en QEMU draait op Proxmox als root, dus het kan de tabel daar rechtstreeks vandaan nemen:

qm set 100 --args "-acpitable file=/sys/firmware/acpi/tables/MSDM"

Naar de live tabel wijzen in plaats van naar een kopie heeft twee gevolgen. Het pad wordt gelezen op de node waar de VM ook maar start, dus dit hoort op een losse host en niet in een cluster: migreer de VM en hij krijgt ofwel de tabel van die node, een andere licentie op een andere machine, of start helemaal niet, omdat QEMU een ontbrekend bestand weigert met can't open file … No such file or directory. En het is één regel, en dus één regel om op een tweede VM te plakken. Die tweede VM is het geval dat de voorwaarden niet dekken, dus één VM krijgt hem en verder geen.

Bouw de functie dus. Het mechanisme deugt, en er zijn klanten die het mogen gebruiken; een die zijn licentie in Duitsland kocht, kan daar best bij zijn. Maar leg het recht waar het hoort: in je servicevoorwaarden staat de klant ervoor in dat hij een licentie heeft die het draaien in jouw VM dekt, en dat doet hij voordat de uploadknop iets doet. De validator bewijst dat de tabel goed gevormd is. Niets bewijst dat hij de zijne is om te gebruiken.

Volumelicenties komen nooit in de buurt van de tabel

Kan een klant met een volumelicentie dezelfde route gebruiken? Nee. Er is niets voor de tabel om te dragen.

MSDM hoort bij het OEM-kanaal en bij niets anders. De eigen planningsgids van Microsoft zegt dat OEM-activering “is available only for computers that are purchased through OEM channels and have the Windows operating system preinstalled”¹². Volumelicenties activeren via een van drie andere modellen, “Multiple Activation Keys (MAK)”, “KMS” en “Active Directory-based activation”¹², en in elk daarvan wordt de sleutel in het besturingssysteem geïnstalleerd. Niets leest hem uit de firmware.

Voor een volumeklant valt er op de hypervisor dus niets te bouwen. Hun sleutel gaat in hun image, en jouw deel is het netwerkpad: poort 1688 naar hun KMS-host, of een VPN naar hun domeincontrollers. Het MSDM-slot blijft leeg, en zo hoort het.

Twee dingen zetten mensen op het verkeerde been. De generieke sleutel op volumemedia activeert op zichzelf niets, want “the GVLK doesn’t work unless a valid KMS host key can be found”¹², dus een VM gebouwd van de Enterprise-ISO van de klant zonder route naar huis blijft ongeactiveerd staan. En een volumelicentie voor de desktop is geen licentie op zich. Volumeprogramma’s “cover upgrades to Windows client operating systems only”, en “an existing retail or OEM operating system license is needed for each computer”¹². De volumelicentie ligt bovenop een basislicentie, heel vaak dezelfde OEM-licentie waar de vorige sectie over ging, en of die in jouw VM mag draaien is nog steeds de hostingvraag in die tabel, geen activeringsvraag.

AVMA verdient een eigen regel, want het is degene die op het antwoord lijkt. Het is de manier van Microsoft waarop een host zijn eigen servergasten activeert, door “the VM activation to the licensed virtualization host” te binden, en het vereist “a Windows Server Datacenter edition with the Hyper-V server host role installed”¹³. Microsoft is duidelijk over de rest: “AVMA doesn’t work with other server virtualization technologies”¹³. Op Proxmox activeren servergasten via jouw SPLA-sleutels of via de eigen KMS van de klant.

Niets in de stack controleert het papierwerk

Elke laag hier doet haar werk en niets meer. De firmware bewaart een sleutel. QEMU kopieert de bytes en ruimt de header op. De gast leest de sleutel en activeert ermee. Geen van hen kan zien of de machine eronder degene is waarmee de licentie werd verkocht, en geen van hen was daar ooit voor bedoeld.

De controle komt dus terecht bij wie de hypervisor draait. Een licentie is een overeenkomst tussen degene die hem kocht en Microsoft, en jouw platform is daar geen partij in, maar het is wel het ding dat de sleutel verhuist, en dat maakt de vraag de jouwe of je erom vroeg of niet.

Schrijf het antwoord op voordat de uploadknop iets doet. Eén machine, één VM, de eigen licentie van de klant en zijn woord dat die dit dekt. Het kost niks, en het beschermt jou net zoveel als hen. De software verhuist elke sleutel die hij krijgt. Of dat had gemoeten, is een vraag die alleen een mens kan beantwoorden, dus zorg dat er een dat doet.