[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 GMT 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...
Klaus
>
>
> 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
>> 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 <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.html>
More information about the vbox-dev
mailing list