Modified Bios for KVM/Qemu/Bochs Bios?

You need to login to view this posts content.

 

Hi Robert,
I add some code at the bottom of the .XML files.

This is how I add SLP in Unraid:

Code:

 <qemu:commandline>
    <qemu:arg value='-smbios'/>
    <qemu:arg value='type=0,vendor=<SLP>,version=<SLP>,date=<SLP>,release=1.0'/>
  </qemu:commandline>
</domain>

Replace <SLP> with the string/s you need.
(just like in other VM software it doesn't work for Dell's SLP)

And I add this for SLIC 2.x in Unraid:

Code:

  <qemu:commandline>
    <qemu:arg value='-acpitable'/>
    <qemu:arg value='file=/PATH_TO_SLIC/SLIC.BIN'/>
  </qemu:commandline>
</domain>

Just add the path to the where you stored the .BIN file on your server.

IIRC, the .XML in Proxmox is set out little different.
So your may have play around with the formatting.

 

You need to login to view this posts content.

 

I was working with a Proxmox server earlier this week so I had a little play with the .CONF files.

I used this to add SLP in Proxmox:

Code:

 args: -smbios type=0,vendor=<SLP>,version=<SLP>,date=<SLP>,release=1.0

Replace <SLP> with the string/s you need.
(again like in other VM software it doesn't work for Dell's SLP)

And I used this for SLIC 2.x in Proxmox:

Code:

 args: -acpitable sig=SLIC,file=/PATH_TO_SLIC/SLIC.BIN

Just add the path to the where you stored the .BIN file on your server.

To add both SLP and SLIC to Proxmox, I added them both together:

Code:

 args: -acpitable sig=SLIC,file=/PATH_TO_SLIC/SLIC.BIN -smbios type=0,vendor=<SLP>,version=<SLP>,date=<SLP>,release=1.0

Hope this helps.

 

Testing Dell SLP
Prior to Version 5.1 the only option was to compile seabos and add: char slp[] VARFSEGFIXED(0x49A9) = "Dell System";
After approx version 5.1 we could used the args command:
args: -acpitable sig=SLIC,file=/PATH_TO_SLIC/SLIC.BIN

And patched /usr/share/kvm/bios-256k.bin with hexedit:
0x349a8 = 0x49A8
00 44 65 6c 6c 20 53 79 73 74 65 6d 00

This worked quite well up through version 8.2-2 since that patch area was a message text area.
The latest version 8.3-1 using QEMU 9.0.2 with Seabios version - 9.0.4, the patch area is not a message area and appears to be executable code. So patching may be unstable.


As stated using the command example:
args: -acpitable sig=SLIC,file=/PATH_TO_SLIC/SLIC.BIN -smbios type=0,vendor='Dell System',version=FBKTB4AUS,date=07/01/2015,release=1.180
while it executes and places the SLP string in the bios, it is not in the valid areas ...........

Have any suggestions other than returning to compiling seabios with the VARFSEGFIXED(0x49A9)????

 

UPDATE: After further researches and experiments, I found that modding OVMF did nothing much. From qemu-system-x86_64.1 manpage:

I struck out to create a new VM with BIOS set to OVMF and enroll Secure Boot keys for it as well. Then I just add two ACPI tables with:

Code:

args: -acpitable sig=SLIC,file=/path/to/DELLSLIC.BIN -acpitable sig=MSDM,file=/path/to/MSDM_DELL_STD25.BIN

OEM SLP and SLIC same as before, I just put it inside MSDM that I won't have to enter.
I also created one unified autounattend disk for basic scripting and automate SLMGR /ILC.

Lo and behold! Windows was activated!

Sniffing the ACPI table from the VM, I saw that both OEM_ID and OEM_TABLE_ID got copied into the XSDT and FACP tables; beside those, SLIC and MSDM tables, nowhere else had any strings even remotely "DELL". In fact, this was the same behaviour from the VM using the modded OVMF.

Some specs (I realised I've not add any yet):

• Host: Proxmox VE 8.3.5
• Uname (minus the hostname): 6.8.12-8-pve #1 SMP PREEMPT_DYNAMIC PMX 6.8.12-8 (2025-01-24T12:32Z) x86_64 GNU/Linux
• VM: q35 OVMF Secure Boot with 1 core x86-64-v3 and 2 GB memory (1 GB ballooned), all using virtio and no PCI passthrough

I'll try and add some photos...
---------------------------------------------------------------------------------------------------------
After fiddling around, I've successfully got a Dell SLP activated in Proxmox VM.

This was tested using OVMF UEFI instance.

My steps:
1. Grab the PVE EDK II from my running host (located in /usr/share/pve-edk2-firmware). I used OVMF_CODE_4M.fd, but I guess any of the ones that said "CODE" and ended with ".fd" should work.
2. Grab a Dell SLIC 2.x to use. I used Dell SLIC 2.7.
3. Use the Phoenix / Insyde / Dell / EFI BIOS Mod tool (thanks @andyp) to modify the OVMF fd.
As far as I know, for me, this tool only inserted the necessary SLP string to the firmware; skipping SLIC insertion here is uncertain, more later...
4. Copy the injected OVMF to a location accessible by PVE host.
5. Create something to deliver the certificate file: I put it in an ISO.
6. Create VM with BIOS set to SeaBIOS (forum proxmox threads combined-ovmf-code-and-vars-file.143553).
7. Open shell and add at the end of file:

Code:

args: -drive if=pflash,unit=0,format=raw,readonly=on,file=/path/to/OVMF_CODE_4M_SLIC.fd -drive if=pflash,unit=1,format=raw,readonly=on,file=/usr/share/pve-edk2-firmware/OVMF_VARS_4M.fd -acpitable sig=SLIC,file=/path/to/SLIC-file.bin

Replace the file paths accordingly: 1st "pflash" is the output file of the modding tool, 2nd one points to the appropriate UEFI variable file (I used OVMF_CODE_4M.fd, so it was OVMF_VARS_4M.fd; drop it altogether if there's EFI disk, haven't tried yet), pointing acpitable to your SLIC (also get uploaded to PVE host) or Windows Activation will say 0x87E10BC6.
8. Install Windows as usual with OEM SLP (mine was Windows Server) and activate.

Notes:
- I haven't tried SeaBIOS yet, because Windows refused to see my boot drive (which is VirtIO SCSI Single throughout the experiment) and keeps boot-looping
- The OVMF image boots much faster than the recompiled SeaBIOS from QEMU source
- Something in QEMU KVM must have done differently, because I had to add the SLIC via "-acpitable" arg in order to successfully activate Windows

 

- The OVMF image boots much faster than the recompiled SeaBIOS from QEMU source

Interesting !!!

I have had a merry chase trying to compile Seabios for Proxmox 8.3 or new 8.4
Seems Seabios source was move into QEMU from Seabios.org at some point.

proxmox / pve-qemu repository has a mirror_qemu folder with binary's but no source. With a mesage "This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository."

Source is found at qemu.org.
Tried to compile in windows with Msys64 .. just to many missing dependencies.

With Ubuntu 24.04.2 in a VM I was able to compile seabios in QEMU Source 9.2.3.

Once the full QEMU Source was loaded

I only had to add:
sudo apt install python3-venv
sudo apt install ninja-build
sudo apt-get install libperl-dev
sudo apt-get install libgtk2.0-dev
sudo apt-get install python-is-python3

Then to compile bios.bin only
cd qemu-9.2.3
./configure
make

Output will be bios.bin
Located in qemu-9.2.3/roms/seabios/out/bios.bin
Just rename bios.bin to bios-256k.bin and copy to proxmox in /usr/share/kvm/

Success !!!!

Then add the VARFSEGFIXED to misc.c and recompile ...
So far in testing the System Locked Pre-installation (SLP) appears to be in the correct location per SLIC_ToolKit_v3.2.exe

 

Searching for SeaBIOS source also led me to fetch it from QEMU. Idiot me compile python2 from source just for the fun of compiling the modified SeaBIOS (gone and fetched the master from GitHub).
On first boot, got greeted with the SeaBIOS version screen for quite a few seconds (15-20, I think), then continued with the boot. Guess something misconfigured in mine then...

So far, the OVMF version turned out to be such fun! Activation was a success for Server 2025; RWEverything did show DELL OEM in both XSDT and FACP tables (no sign of RSDT, weird...);... All except for SLIC_Toolkit_v3.2.exe: RSD PTR not found... huh! Well, RWEverything did saw the SLIC table, though...

 

Another thing I've learned: If you're not using Legacy Option ROM, you don't need to worry about RSDT!

I've had a chance with a physical computer with OEM SLIC built-in (still trying to replace it, AFAIK); SLIC Toolkit will straightout error because it cannot find RSDT tabe, but RW Everything will dump ACPI tables just fine.

I guess the takeaway is: If OVMF is used, just add the -acpitable for SLIC, I guess...