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 > <[email protected] <mailto:[email protected]>> 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 > [email protected] <mailto:[email protected]> > 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.
_______________________________________________ vbox-dev mailing list [email protected] https://www.virtualbox.org/mailman/listinfo/vbox-dev
