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

[Ribhi Kamal]

Thanks Klaus,
Having no plan is a good plan.

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.

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

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


On Thu, Jun 25, 2020 at 7:36 AM Klaus Espenlaub <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 6.1.8.0 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
> 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/20200625/6f47d9ce/attachment.html>