Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Release-signing for Windows Xen PV drivers #9019

Open
omeg opened this issue Mar 7, 2024 · 1 comment
Open

Release-signing for Windows Xen PV drivers #9019

omeg opened this issue Mar 7, 2024 · 1 comment
Labels
C: windows-tools C: windows-vm P: critical Priority: critical. Between "major" and "blocker" in severity. T: enhancement Type: enhancement. A new feature that does not yet exist or improvement of existing functionality.

Comments

@omeg
Copy link
Member

omeg commented Mar 7, 2024

Currently the Windows PV drivers are test-signed because upstream doesn't provide signed binaries anymore. This requires all Windows VMs to enable test mode which is not ideal. Release signing requires a few steps:

  • A proper code signing certificate (any authenticode one from a public CA is fine).
  • Windows Hardware Compatibility Program certification. The drivers need to be tested in the Hardware Lab Kit with a proper set of rules, then the (passing) results sent along the binaries and the signing cert to Microsoft for certification. If all goes well we receive MS-signed binaries back.
  • Some modifications to the Xen backend/pvdrivers might be needed, specifically to change the PCI device IDs so they don't conflict with the upstream values. From my understanding only one set of drivers for a particular set of hardware IDs is permitted.
  • Changes to the building process to accommodate using a release cert, probably from an external storage/card reader.

We would gain some significant usability improvements from this:

  • The drivers could be distributed via Windows Update, no need to bundle them with Qubes Windows Tools.
  • No need for test signing being enabled so reduced OS attack surface.
  • Possibly automatic crash dump collection from Windows Update (hopefully not needed).

There are some disadvantages too:

  • The cost for the code signing cert (a few hundred dollars per year).
  • HLK testing is pretty involved and requires a special multi-VM setup. I wasn't able to get it to fully work in Qubes, there were some weird connectivity issues despite the VMs being properly connected via network. I was able to do tests in a native Windows environment though.
  • HLK certification needs to be done for every update (tests can easily take more than a day to fully run).
@omeg omeg added T: enhancement Type: enhancement. A new feature that does not yet exist or improvement of existing functionality. C: windows-vm P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. labels Mar 7, 2024
@DemiMarie
Copy link

  • The drivers could be distributed via Windows Update, no need to bundle them with Qubes Windows Tools.

Bundling them with QWT is still a good idea, because it works even when the VM is offline.

@andrewdavidwong andrewdavidwong added P: major Priority: major. Between "default" and "critical" in severity. C: windows-tools and removed P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. labels Mar 19, 2024
@andrewdavidwong andrewdavidwong added P: critical Priority: critical. Between "major" and "blocker" in severity. and removed P: major Priority: major. Between "default" and "critical" in severity. labels Apr 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: windows-tools C: windows-vm P: critical Priority: critical. Between "major" and "blocker" in severity. T: enhancement Type: enhancement. A new feature that does not yet exist or improvement of existing functionality.
Projects
None yet
Development

No branches or pull requests

3 participants