[vbox-dev] Windows 10 WDK/SDK and VCC 2019 toolset upgrade plans

Klaus Espenlaub klaus.espenlaub at oracle.com
Fri Jun 26 19:16:20 UTC 2020

Hi Ribhi,

On 2020-06-25 15:38, Ribhi Kamal wrote:
> Thanks Klaus,
> Having no plan is a good plan.

To some extent I can relate to that concept...

> Here are Microsoft's own words, I'm going to put my understanding of
> each bullet point.
>     /Attestation signing has the following properties.
>     Attestation signing supports Windows 10 Desktop kernel mode and
>     user mode drivers. Although user mode drivers do not need to be
>     signed by Microsoft for Windows 10, the same attestation process
>     can be used for both user and kernel mode drivers./
> If vboxdrv is a user mode driver, I believe this means that it just
> needs to be signed by an EV cert and doesn't even require attestation.
> Only Pnp drivers and filter drivers require it.

It's a kernel driver of course, and all of them need attestation
signing. It's implementing a fully virtual device, so it can't really be
PnP. Windows 10 doesn't care about some of the at best partially correct
documents which Microsoft has published on drivers and signing.

>     /Attestation signing will not return the proper PE Level for ELAM
>     or Windows Hello PE binaries. These must be tested and submitted
>     as .hlkx packages to receive the additional signature attributes./
> We don't use ELAM or Windows Hello, so we don't care.
>     /Attestation signing requires the use of an EV Certificate to
>     submit the driver to the Partner Center.
>     An attestation signed driver works on Windows 10. It does not work
>     on earlier versions of Windows, such as Windows 8.1 and Windows 7,
>     and is not supported for Windows Server 2016 and later. For more
>     information about the support policy, see Support policy for
>     third-party, kernel-level software that is signed by using the
>     attestation process in Windows./
> Although I didn't personally test it, you won't be able to load your
> drivers on Server 2016 and above with just attestation. Windows 8.1
> might be an issue if secure boot is enabled. Windows 7 doesn't support
> secure boot as far as I recall, so that won't be an issue. Windows 8
> is an unknown. 

Right, Windows Server allegedly isn't satisfied with attestation signing
- but for some odd reason I don't remember anyone complaining...

>     "So you're creating a chimera between kBuild for VirtualBox trunk
>     and the code of VirtualBox 6.1"
> I agree, that's why I stopped what I was doing. The problem is that I
> need to base my work on something that is release quality. I can work
> directly from trunk but as you said trunk is full of unfinished
> projects. My plan was to get it working with the latest 6.1 release
> and then try to apply the changes on top of trunk, but whatever
> changes I make will likely undo the work being done right now to
> support 2017. I think if there is an upgrade effort on your side, it
> makes a lot more sense to target 2019 instead.

2019 should be already working by now, but you didn't get that yet
because I didn't find time to trigger updating the public repo. And
today it's again already too late. Next week, I hope...


> On Thu, Jun 25, 2020 at 7:36 AM Klaus Espenlaub
> <klaus.espenlaub at oracle.com <mailto:klaus.espenlaub at oracle.com>> wrote:
>     Hello Ribhi,
>     On 2020-06-25 06:06, Ribhi Kamal wrote:
>>     Hello VirtualBox,
>>     TL;DR; I noticed that there are attempts to get VirtualBox to
>>     compile using VS2017. I was hoping that you would be so kind as
>>     to share with me your plans (if any) to upgrade the tools for
>>     compiling VirtualBox for windows hosts and which WDK, SDK, VCC
>>     are you planning to upgrade to. I'm attempting to upgrade but to
>>     the latest of everything.
>     No point talking about this ongoing project until it is completed.
>     The result isn't clearly defined yet, and what's even less clear
>     is when this will hit the first release. It's not terribly likely
>     (but also not impossible) that it will be ever available for

>     VirtualBox 6.1. It's the nature of "trunk" that there are 
>     unfinished projects where we cannot make any commitments.
>>     The long version.
>>     About ~three month ago, a client reached out and requested that
>>     virtualbox drivers have complete secure boot support on Windows
>>     10. This meant going through HLK since attestation did not
>>     provide complete support. Long story short, I agreed to give it
>>     a shot.
>     Can you please describe what's incomplete about attestation
>     signing? According to the Microsoft documentation, it is the
>     minimum requirement for recent Windows 10 to accept the drivers.
>     No word anywhere that this is in any way 2nd class, and no one
>     other than you have reported problems with the drivers we're shipping.
>>     After setting up the HLK environment, I used an already compiled
>>     OSE version of virtualbox that I had on hand to do some basic
>>     testing to see what kind of tests are failing. The results were
>>     promising considering that I was using V4.2 that was compiled
>>     eons ago using vs2010.  Some failing HLK tests required silly
>>     things like having a four digit version for the driver (aka
>> vs 6.1.8) while others seemed to be way more involved.
>>     But the following was obvious:
>>     1- In order to pass HLK, a good reliable way was needed to bridge
>>     a hostonly adapter to a physical nic. The version that I was
>>     using didn't even have support for bridging on windows 10. My
>>     attempts to create a tunnel between two virtual machines failed
>>     as packets would suddenly start dropping. I believe this was an
>>     issue with vbox net service. So an upgrade to virtualbox was
>>     needed to see if using virtualbox bridging will work.
>     Another 'problem area' where you seem to be telling just the
>     uninteresting part of the story. I doubt that there is really a
>     hard requirement that a fully virtual adapter needs to somehow
>     bridge to a physical NIC...such virtual adapters are quite common
>     (VPNs, ...) and your test approach seems unusual.
>>     2- The drivers must be compiled to target windows 10. Though,
>>     from experience, I know that you can target windows 7 and above
>>     and still pass the HLK and have a single driver that supports all.
>>     3- The drivers must be compiled using the latest WDK.
>     Can't believe that Microsoft is really so picky, because that
>     would make Win10 drivers incompatible with older OS versions.
>     Causing a big mess with installing the right driver for older
>     Windows versions when the code is exactly the same.
>>     I set out to work on the upgrade process with the hopes that I
>>     could get it to work and either share with you what needs to be
>>     done or submit patches (if you are interested). If and when I
>>     pass the HLK tests, I would share with you my setup as well.
>>     All the prerequisites compiled fine without any headache for both
>>     32bit and 64bit using vs2019. The instructions for building them
>>     using vs2010 needed small adjustments to make everything work.
>>     Next was virtualbox. I pulled down the latest virtualbox tgz
>>     tarball at the time (6.1.8) and started upgrading the tool
>>     sets.Then I started by upgrading kbuild by adding an SDK, VCC and
>>     WDK kmk files and updated configure.vbs to correctly detect the
>>     tool sets and configure kbuild. I was starting to have some
>>     success when I noticed that kbuild already has updated VCC and
>>     SDK (but no WDK). So I pulled these down and replaced the work
>>     that I did with kbuild's and patched the files with any required
>>     updates. Then I noticed that VirtualBox SVN source tree has
>>     already been updated to the latest kbuild and new options were
>>     being added to support VS2017 (I think). But I did not see any
>>     mention of the WDK, only the Windows 8. Whatever was going on, it

>>     seemed like work in progress. So I started to worry that
>>     everything that I'm doing is potentially a duplicated effort.
>>     That's why I'm interested in knowing your upgrade roadmap if you
>>     have one.
>     The kBuild used for 6.1.x has none of the updates you mentioned.
>     So you're creating a chimera between kBuild for VirtualBox trunk
>     and the code of VirtualBox 6.1. Not a supported combination ever,
>     and possibly causing all sorts of issues.
>>     Currently, I feel like I'm very close to getting all the user
>>     mode binaries to work. They currently compile but there are some
>>     linking issues that I'm trying to address. The next obstacle is
>>     going to be the removal of selfsign since it no longer exists in
>>     the WDK.
>     Those "some linking issues" could be anything, and since it's very
>     unlikely that 6.1 will ever be officially built with anything
>     except VS2010 there isn't all that much motivation on our side to
>     spend time on this.
>>     p.s. My main focus was to get the host drivers working first and
>>     then focus on the guest additions. I didn't know there are guest
>>     additions that go as far back as Windows NT!
>     Everyone underestimates the guest additions :) On the host there
>     is a much smaller range of OSes which is relevant. The guest
>     additions ideally work with absolutely everything which Microsoft
>     ever released. After all one purpose of VirtualBox is to run old
>     OSes in a safe manner.
>     Klaus
>>     Thanks and stay safe,
>>     -- 
>>     Ribhi
>     _______________________________________________
>     vbox-dev mailing list
>     vbox-dev at virtualbox.org <mailto:vbox-dev at virtualbox.org>
>     https://www.virtualbox.org/mailman/listinfo/vbox-dev
> -- 
> Ribhi
> This communication may contain information that is legally privileged,
> confidential or exempt from disclosure. If you are not the intended
> recipient, please note that any dissemination, distribution or copying
> of this communication is strictly prohibited. If you receive this
> message in error, please notify the sender immediately by telephone or
> by return email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.virtualbox.org/pipermail/vbox-dev/attachments/20200626/3948472c/attachment-0001.html>

More information about the vbox-dev mailing list