Windows 11 on ARM64 Support #289
Comments
|
As of now no way -- as per the comments from the above two issues. |
|
Hello, I found the arm64 adb and fastboot driver in the relevant Windows of Android group today. After testing, it can connect to the phone and read data normally. The relevant driver accessories have been uploaded. Success picture |
|
I think I may have found a workaround. You need to disable Driver Signature Enforcement in Windows. To do that, you need to reboot your Windows into a Safe Mode (Start Menu, right click on power button, and hold SHIFT while clicking on Restart). While in the safe mode, go into Troubleshoot / Advanced Options / Startup Settings. Click Restart, select option 7 (Disable Driver Signature Enforcement). Once the Windows reboots, install Zadig drivers as usual. I'm running Win 11 Pro in Parallels on Mac and it works well. My setup:
|
|
Please don't spam. Your proposed "workaround" is well know, and is not a real workaround, since it forces the user to disable something that Zadig was designed to prevent them from having to do (since it does put a user's computer at risk). A proper workaround would be to identify a registry setting , Group Policy or any other Windows configuration parameter that one can enable that doesn't disable signature enforcement altogether and makes Windows 11 on ARM64 behave like Windows 11 on x86, by making the |
|
Zadig driver has to submit to Mircosoft Hardware Certification, if it want to run in Windows 11. But it deviated from the purpose of users using Zadig. Starting with Windows 10, version 1607, Windows will not load any new kernel mode drivers which are not signed by the Microsoft through the Hardware Dev Center. Valid signatures can be obtained by either Hardware Certification or Attestation. I purchased the EV certificate required by Microsoft and registered it on Microsoft's hardware Certification. I submitted the driver generated by Zadig to the platform and received a signed driver in return. This driver can be used successfully on Windows 11 ARM. |
Except what we are discussing does work on Windows 11 x64. Also Zadig does installs drivers that have passed the MS Hardware Certification (one of them being WinUSB, which is produced by Microsoft themselves). And Zadig follows Microsoft's own guidelines that one should be able to sign a driver package and, if the driver package's signature certificate can be found in Trusted Publisher (which is the part that Zadig does: it does install a one-time-use certificate under Trusted Publishers), then the system will consider the driver package as trusted and install it. This works fine on Windows 11 x64. Therefore, there is a default system configuration difference between Windows 11 x64 and Windows 11 ARM64, that has nothing to do with using EV certs and whatnot, that needs to be identified, so that Zadig can install drivers on Windows 11 ARM64 the same way it is able to install drivers on Windows 11 x64. This is not a "kernel driver has not gone through the Hardware Dev Center" or "kernel driver has not been signed with an EV certificate" issue. ALL the drivers that that Zadig installs have. Instead, this is a "Microsoft has broken a promise it made that one could sign a driver package (which is different from the driver binaries) and that, if the signature's certificate could be found in Trusted Publishers, that package would be installed on systems where signature validation is active". Your report, which we already know about, only demonstrates that, on ARM64, the default configuration of Windows is that it will only accept for a driver package EV certificates whereas, on x64, it does accept non EV certificates that have set to be trusted by the system. And again, this is different from the default x64 Windows configuration. |
This adds support for loading libusb0.sys on ARM64.
Either the rules were changed, and we need to adapt, or win11-arm64 completely disabled the self-signing feature. |
Thanks. You may want to submit a PR as it's likely to be some time before I can look into adding this, and I may forget about otherwise.
To adapt we need to find what is the difference in default configuration (since Windows should use the same codebase, so it has to be a configuration setting) between x64 and ARM64. Until someone can provide some hints on that, there will be no change. Worse, chances are that Microsoft is going to bring this default configuration to x64 in a feature update eventually (because we have seen the exact same issue with Insider releases a couple years ago), so the clock is probably ticking for x64 users as well... Now, as you may have realised, I have very little time to devote to libwdi these days, so it's very unlikely that I will be able to invest the time required to look into the ARM64 issue, which means that somebody else will probably have to step up... |
You mentioned in #155 that you work for Microsoft and you are interested to get libwdi to work for Windows on ARM64. Just wondering if you can help to clarify the direction from Microsoft in this aspect. Thanks a lot in advance. |
|
For the record, my current guess is that whereas the (current) official documentation states:
thereby indicating that a driver packages where the signing certificate is present in Trusted Publishers should lead to driver installation, Microsoft might have introduced features of Windows S mode to Windows on ARM64, and especially:
thereby excluding self-signed credentials where the certificate part gets installed in Trusted Publishers. However, as opposed to S Mode vs regular mode driver package installation differences, I have not been able to find any documentation related to x64 vs ARM64 driver package installation differences... |
|
Let me ask in OSR ntdev mailing list. |
|
OSR thread posted here. Let's see if we get some comments from the experts there and hopefully from Microsoft developers. |
|
Much appreciated, Xiaofan. At this stage, I feel that short of someone from Microsoft shedding light on the difference in behaviour, not much progress will be made on the issue. |
I agree. I tend to believe that Windows on ARM64 follows Windows S mode requirement. To install on Windows 10 in S mode, driver packages must meet the following requirements:
|
|
Caveat: I do work for Microsoft, but I don't represent Microsoft. I don't even work adjacent to driver signing bits, but I care a lot about ARM64 [edit: for professional as well as personal reasons] and look forward to one day using Last I dove into it, ARM64's driver signing requirements are the same as x64 except that My first guess is based on the...learning curve for a few issues at work: a combination of shiny features in ARM64 hardware and OEMs enabling OS features that rely on that hardware might trigger an extra harsh driver signing policy somewhere. (How much easier is it to attack Device Guard, HyperVisor-enforced Code Integrity, or Secure Kernel if it's trivial to load arbitrary kernel-mode code? Counterpoint, as a device owner and administrator, don't I get to decide whom I trust? What fun. Enabled OS security features can take a lot of the guesswork out of the first question by answering the second question 'no' [edit: more like "no, you asked us to run security"], so they often do.) I'd look through I'll poke at my Lenovo X13s a bit to see what I can see. |
Thanks @jkunkee, the attestation signing is being totally deprecated. But that means I have to go through HLK every time I want to publish a new driver? Or have you seen other, newer ways to fast-sign a valid driver? |
|
@jkunkee, thanks a lot for looking into it. We appreciate all the help we can get on this, regardless of where it comes from. In case that's needed to help you understand our issue better, I'm just going to point out that we're not trying to self sign the drivers themselves for installation (i.e., we're not doing attestation-signing for driver binaries) as, for all intents and purposes, you can consider that the driver we are trying to install is the (unmodified) Microsoft-signed WinUSB driver, which is already present as a system driver, and that we are repackaging to tell the system "Hey, you should also apply that driver to USB device So, all we are signing as part of libwdi, using a locally created certificate and key, is the driver package, i.e. the .inf and a list of files. Basically, it boils down to signing:
(NB: technically, since the In other words, at no stage is libwdi trying to sign binary executables, and especially, it's not ever trying to sign kernel binaries to try to get them installed on the system. And it is the certificate that was used to sign the driver package that libwdi installs in Trusted Publishers, so that, as has been the case on all versions of Windows until Windows 11 ARM64 (including current Windows 11 x64), the system will agree that the driver package can be trusted to start driver installation (and, as part of the installation process, can now perform a completely separate binary driver signature validation, on any kernel binary files that are to be installed). So, the only logic that makes sense to try to restrict signed driver packages not to be trusted unless they use a non locally vetted certificate is if Microsoft now (or at least on ARM64) considers that Oh, and I searched for |
I had this wrong. I'm told attestation signing is fine for ARM64 Client and is not deprecated. (I really need to find good external docs to point to about this; I can't be a source of truth for this, and anyways, I've already gotten it wrong once.) I'll write more on this thread when I find it. RequireHardwareSecurityFeatures is a Value, not a Key, if that helps any. The docs I linked provide exact paths. Sorry this is so terse. |
Thanks so much for this. I wasn't able to find an answer and so would differ that this isn't well known and is a workaroud. By it's very nature is safe "for technically minded people", the option is very hidden in Windows and on my Surface Pro X even had to enter my Bitlocker Recovery Key to get to this option. I'm pleased to add you only need to do this "to install the driver" and "if you change the physical device". Once installed it continues to work even with Driver Signature Enforcement re-enabled. Thanks again. |
This is fairly interesting. This means they did not change the signing rules for ARM64, but merely changed the driver installation rules which is not even in kernel space, but probably in some installation DLL (setupapi.dll or similar). It still is a killer for Zadig, so it would be great if MS could fix this, as this does make self-signing stuff not work at all, which looks more like a bug than a deliberate decision due to the point you just made. |
Not exactly. It forces self-signing to be accomplished using an Authenticode certificate rather than a locally created one because (as far as I can tell) Microsoft restricted the driver package signature validation rules on ARM64 to no longer validate signatures whose certificate chain ends up in the system's "trusted" publishers (which encompasses both the Trusted Publishers store and the Trusted Root Certification Authorities, because validation breaks on ARM64 even if you install the cert in Trusted Root Certification Authorities) but instead only validate against a different internal trust chain, that includes Authenticode providers, but that the user no longer has any control on. In short, it appears that, with the default Windows configuration settings of ARM64, Microsoft has done away with any form of trust chain where the user could exert some form of local control, to instead force everyone into the hand of third party trust only which, from a security standpoint, is quite the jump as we are talking about trust, and, in effect, Microsoft has taken away the ability for users to have any say about who they decide to trust (or not to trust), whereas this ought to be a fundamental freedom that any OS (or pre-OS environment) should always grant its users. Heck, even Secure Boot, which is a pre-OS environment, does not take away this kind of freedom as a proper implementation allows its user to use Setup Mode to install their own keys if they wish, which can be/usually are locally generated ones (and since you can still install the Microsoft Secure Boot certs, Windows will happily run with Secure Boot enabled in such an environment. And even better, at this stage, it is the user who chose whether they decided to trust Microsoft enough to run Windows on the hardware they own, rather than the other way around). Yet, when it comes to driver installation on ARM64, it appears that Microsoft has decided that removing the ability, for Windows users, of deciding who they trust was ultimately better... for them? Anyway, to get back to the point, I don't believe this is a bug (especially as we have seen this behaviour appear in x64 Windows 11 Insider releases before, even as it's never made it to a formal x64 release yet), which seems to indicate that this is a deliberate restriction that Microsoft has been wanting/planning to introduce for some time, and ultimately decided that ARM64 was the best place to do. I am also pretty sure that the people who pushed to introduce this "feature" consider that there is no much of an issue with it, since people should "just" be able to sign their driver packages with third party Authenticode credentials (which of course, software like Zadig will never ever be able to do). |
|
I am more hopeful that Microsoft may change this policy once Windows on ARM64 gains some level of popularity. Right now I consider it as a failure in terms of market share. Once Microsoft ends exclusive relationship with Qualcomm and allows more vendors to come into the market, they may have to change the policy. But maybe it is just my wishful thinking... |
Maybe. But why would they leave it open in the kernel driver loader, and then only restrict things when installing new drivers? That is why i concluded it was a bug, but you might be right. It just seems odd from a security perspective to not allow something, but then still allow it if someone sneaks it in while your not looking (e.g. by temporarily disabling the enforcement). |
|
If Microsoft wants enterprise customers to use Windows on ARM64, they have to allow this method in the end. Reference: Peter_Viscarola_(OSR) said in the above thread.
|
The user has to actively jump through several hoops to do this I suppose. It's always been a buried option.
Agreed with this. To many businessse and enterprises will expect this. Right now whilst WoA numbers are low it's not hurting Microsoft but I expect numbers to grow eventually. |
Done. |
|
For those looking for some kind of (not ideal) workaround for this situation, please see this entry from #288. |
Same, currently unable to do anything with my switch on my new Surface Laptop 7 :/ |
|
Indeed with the new generation of Qualcomm Copilot+ laptops, Windows on ARM64 will be more popular (but I am not going to buy this generation of Qualcomm laptop). Let's see if Microsoft is willing to change the policy but looks not easy. |
A couple of thoughts around this (though I must stress I do not speak for Microsoft, my employer): Really, this sounds like a bug to me since the aim I've generally seen is x64==ARM64 and "it's just Windows". (Windows RT is long, long dead; I helped bury its bones.) The first place to file a (concise, detailed, actionable) report is, yes, Feedback Hub. It may be helpful to share a Feedback Hub shortlink here so others can upvote it. It's even possible there's already an item for it; either way, I'd love to see it. If you're an enterprise customer that wants to use Windows on ARM64 and one of your applications doesn't seem to be fully compatible (like, say, Zadig hitting the issue described here) or an enterprise feature is not working (like self-signed driver deployment via device management), ask your sales team about the App Assure program. They tend to get stuff fixed if it's anywhere in Microsoft code, and they'll even attempt to work with third-party software vendors if that's where the issue is. (Also, Parallels is a supported platform as of IIRC last year.) If you're not an enterprise customer that can leverage App Assure and/or you have questions about ARM64 Windows, there's also the email address mentioned at the end of this page staffed by a handful of folks who know a few things and are pretty helpful. |
I tried to install WinUSB on Huawei's ARM laptop and encountered the same driver signature issue as before. I attempted to restart the computer and start it in a way that disabled driver signature, which allowed me to successfully install it. Is there a way to install WinUSB without disabling driver signature?
link:
#288
#155
The text was updated successfully, but these errors were encountered: