<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Thanks Klaus,</div><div>Having no plan is a good plan.</div><div><br></div><div>Here are Microsoft's own words, I'm going to put my understanding of each bullet point.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><i>Attestation signing has the following properties.<br>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.</i></blockquote>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.<br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><i>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.</i></blockquote>We don't use ELAM or Windows Hello, so we don't care.<br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><i>Attestation signing requires the use of an EV Certificate to submit the driver to the Partner Center.<br>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.</i></blockquote><div>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.  </div><br></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div dir="ltr"><div>"So you're creating a chimera between kBuild for VirtualBox trunk and the code of VirtualBox 6.1"</div></div></blockquote><div dir="ltr"><div>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.</div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 25, 2020 at 7:36 AM Klaus Espenlaub <<a href="mailto:klaus.espenlaub@oracle.com">klaus.espenlaub@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div>
    Hello Ribhi,<br>
    <br>
    <div>On 2020-06-25 06:06, Ribhi Kamal wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">
        <div dir="ltr">Hello VirtualBox,
          <div>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.</div>
        </div>
      </div>
    </blockquote>
    <br>
    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.<br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div dir="ltr">
          <div>The long version.</div>
          <div>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.</div>
        </div>
      </div>
    </blockquote>
    <br>
    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.<br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div dir="ltr">
          <div>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:</div>
          <div>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.</div>
        </div>
      </div>
    </blockquote>
    <br>
    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.<br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div dir="ltr">
          <div>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.</div>
          <div>3- The drivers must be compiled using the latest WDK.</div>
        </div>
      </div>
    </blockquote>
    <br>
    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.<br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div dir="ltr">
          <div>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.</div>
          <div><br>
          </div>
          <div>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.<br>
          </div>
          <div>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.</div>
        </div>
      </div>
    </blockquote>
    <br>
    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.<br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div dir="ltr">
          <div>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.</div>
        </div>
      </div>
    </blockquote>
    <br>
    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.<br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div dir="ltr">
          <div>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!</div>
        </div>
      </div>
    </blockquote>
    <br>
    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.<br>
    <br>
    Klaus<br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div dir="ltr">
          <div><br>
          </div>
          <div>Thanks and stay safe,</div>
          <div>-- <br>
            <div dir="ltr">
              <div dir="ltr">
                <div>Ribhi<font size="2" face="Verdana, Arial, Helvetica, sans-serif" color="#666666">
                  </font></div>
              </div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
  </div>

_______________________________________________<br>
vbox-dev mailing list<br>
<a href="mailto:vbox-dev@virtualbox.org" target="_blank">vbox-dev@virtualbox.org</a><br>
<a href="https://www.virtualbox.org/mailman/listinfo/vbox-dev" rel="noreferrer" target="_blank">https://www.virtualbox.org/mailman/listinfo/vbox-dev</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div dir="ltr">Ribhi<br></div><div dir="ltr"><br></div><div dir="ltr"><span style="color:rgb(165,165,165);font-family:Arial,sans-serif;font-size:10px">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.</span></div></div></div>