The article mentions Process Explorer. Since Sysinternals were bought by Microsoft many years ago and the tools are distributed directly via Microsoft, such tools are unlikely to have an issue being signed.
A brief history of the process for those not following it. Originally for kernel-mode drivers, you needed a code signing certificate cross signed by Microsoft's root. This means that the certificate follows a chain up to a standard CA _and also_ one Microsoft use to approve that CA to issue kernel-mode certificates. It was not sufficient to have a certificate capable of signing code, even with MS' OIDs for that.
Then, around Windows 10 I think, Microsoft announced that one would need to acquire an EV certificate. You would then be required to submit the driver package via sysdev.microsoft.com and after spending time in Ballmer's Brewery, it would come out signed by Microsoft.
It was technically possible to use the old mechanism at this stage too, provided the end user did not have UEFI secure boot enabled. IF secure boot were enabled, the kernel would: a) if the driver was signed pre-Win10, accept it, b) if it was signed post win-10 RTM date and by Microsoft, accept otherwise reject.
Thus the only mechanism to realistically get your driver working on all Windows out of the box is to submit via sysdev. You can't realistically ask users to disable secure boot, even if this is entirely possible on all x86 motherboards.
Finally, the cross signed roots expire soon and I think some already have. Microsoft have decided that this mechanism will now be retired, and all drivers must be signed via sysdev from now on. You still require an EV certificate as well, to sign the package.
This is a bit of a mixed bag. On the one hand, Microsoft have repeatedly signed the shim maintained by redhat in order to allow Linux distributions to boot directly on secure boot-enabled hardware (UEFI binaries also go through this process and always have). Microsoft have their keys in the default keychain because they bothered to be involved in the process, unlike linux companies like Redhat. So on the one hand, they're being quite friendly to open source.
On the other hand, the push to EV certs rules out individual developers like myself[1]. I could register a company but... that entails effort and expense for a hobby project. And now hobbyist projects like this run the risk of being rejected by MS.
I mostly believe this is an attempt to reduce the number of code signing cert leaks that result in people writing malware, and lock down the Windows kernel a bit more, but still. It is a shame.
[1] This is because most CAs won't issue EV certificates to individuals, even if those individuals happen to have detailed knowledge of cryptography and all the pkcs.
> Microsoft have their keys in the default keychain because they bothered to be involved in the process, unlike linux companies like Redhat.
The status quo was that systems could boot any operating system the user wanted. Microsoft tried to force OEMs to lock operating systems other than those on a very short list (they tried to force Secure Boot to be enabled with no way for users to turn it off, and you can confirm this by checking out earlier versions of the UEFI spec), knowing very well that that list would always include Windows for pretty much every computer out there, but you try to spin this as it somehow being every other vendor's fault for not getting in on that list with each and every manufacturer?
There are two sides to this coin. Firstly there's the hardware vendors who make firmware, who decided to incorporate UEFI presumably because intel pushed it hard (original efi booted itanium and is also found in older Macs).
That's from Matthew Garrett, who along with Peter Jones, were responsible for the first shim.
A central authority like the Linux foundation could have stepped up here and could have since, actually. I understand why fedora/redhat preferred not to be in a privileged position but I can't help but feel someone ought to have stepped up.
The other side of the coin is the windows logo program, that requires secure boot be turned on by default. For x86 I'm fairly sure it also requires that the user can take control of the platform key and therefore evict Microsoft keys from the firmware. It also requires that secure boot should be disabled. I'm fairly sure Microsoft did this because they realised there would be objections otherwise
Microsoft's ARM hardware _is_ locked down with no such options and I object to that wholeheartedly. But then I also don't buy Apple kit for daily driver use for the same reason. Also luckily Microsoft are currently irrelevant in the arm space, although that might change with the serverready profiles.
I am sure the process was onerous, but someone could have done it. Linux is big business in the server hardware space and intel for example contributed the thunderbolt code to the kernel. I am fairly sure they could between them organise a foundation and throw a few 100ks per year at maintaining a signing key for other distros independently to Microsoft.
I don't believe any entirely locked down firmware ever made it into any x86 board.
> Microsoft's ARM hardware _is_ locked down with no such options
That was for 32-bit Windows on Arm hardware. 64-bit Windows on Arm laptops/tablets have unlockable Secure Boot, with a regular SETUP interface and all.
All this does make Microsoft sound very reasonable, actually. People have been painting dystopian pictures of an ultra-locked down hardware future, complete with evil corporate overlordship etc for many years. Really as long as I've been using computers. Yet, here we are in 2021 and not only old hardware is still open but newly designed hardware too, and Microsoft has even been ensuring that platforms which didn't get the memo (mobile, ARM) open up.
The problem with a completely unlocked bootloader is that the distinction between "a Linux distribution" and "malware" is not one that can be decided technologically. Otherwise malware could just install a heavily customized Linux kernel that directly boots into Windows, hot-patching it along the way, and who is to say it's not really Linux? Someone has to make that call for the ordinary userbase that doesn't care about operating systems and it sounds like out of an ideological fit of pique - what a surprise - Linux vendors just noped out and refused to do their part. Because, you know, malware is other people's problem. So now Microsoft finds themselves carrying water for their own competitor.
Given Microsoft's losses with eg Windows mobile, their late entry into the cloud space, giving up on making their own web browser (engine), Microsoft's forced to play nice in order to compete.
I don't understand your second part though. What is the "step up" available to Linux vendors that they didn't do?
I feel maybe I should elaborate on this more because a lot of people in this thread don't seem to quite understand the UEFI thing. Yet I cannot see an error or oversight in the chain of logic, so Linux vendors really deliberately screwed themselves over here and it's quite impressive actually that Microsoft bailed them out.
1. Computer makers want to sell computers to the masses. This is reasonable.
2. The masses don't want un-removable malware that renders their virus scanners useless. Also reasonable.
3. Malware writers want to beat virus scanners by taking over the OS before it even boots, which is an unassailable position for them. This is "reasonable" from their POV. Likewise, computer makers - not just Microsoft - want to stop this from happening because it's a kinda game over move and there's nothing that really prevents it (pre UEFI) other than the fact that the programming is kind of tricky.
4. To fix this the computer maker must have some opinion about what the computer is willing to boot. Boot-loading code is henceforth separated into "good" code that makes users happy by letting them surf the web, print etc and "bad" code that makes users unhappy by screwing with their machine and data and possibly bank accounts. This appears to be unavoidable and can be implemented with cryptography.
5. But computer makers don't really want to have such an opinion because it's a live wire for geeks who run obscure operating systems. They just want to get rid of malware. So they need a default, reasonable whitelist that will make users happy, and then a way to edit that whitelist that is too difficult for users to get phished or scammed into doing by accident. Whitelisting public keys in the UEFI/BIOS screen seems like a reasonable approach to this.
6. To have a signing key that's shipped out of the box you must agree to some simple rules, like, you must actually not be malware, and you must not accidentally sign malware, and you must protect your key, and you must not sign a piece of software so open that it can be trivially wrapped around malware. The first three are easy but the sorts of guarantees best made by an institution, not an individual. Microsoft is an institution. "Linux hackers" are not. But, there is a Linux Foundation that could play the role and helpfully already own the Linux trademark (I think), so they already kinda get to decide what is and isn't really Linux.
7. The final condition is the harder one because it implies a chain of trust. Otherwise the malware writer can just create a bespoke Linux that boots into a minimalist Linux environment and then immediately unloads Linux and chains onwards to a patched Windows. So each whitelisted Linux distro needs to have a default opinion about what can run in kernel mode that is (again) overridable, but only by people who know what they're doing. Which Linux can do, via module signing. So no technical problem here.
8. At this point Linux vendors appear to have flounced out of the room and collectively decided they can tell the PC industry what to do by refusing to take part in the process. They were wrong, nobody gives a shit about desktop Linux because it has hardly any users. However they only realized this way too late, by which time PCs were already shipping without any Linux Foundation keys in the whitelist. What to do?
9. Answer: go crying to your primary competitor and pressure them/ask them nicely to fix your fuckup by using their own cert to sign your operating systems.
This is kind of pathetic and it appears the Linux community has still never got its act together and set up a key whitelisting process.
Take part in the UEFI secure boot process to get a key whitelisted that'd be shipped in hardware out of the box (e.g. one managed by the Linux Foundation).
> I don't believe any entirely locked down firmware ever made it into any x86 board.
There are some Android x86 devices that won't boot unsigned firmware and won't let you change the signing keys. But I've only seen that in non-BIOS, non-UEFI devices.
Your text is written in past tense. But if there is a maintained list why is nobody working to get linux vendor keys in now? Yeah, it'll take a while for the hardware cycle to refresh, but it's better than nothing.
qBittorrent developers just said fuck it three years ago, and let the world burn with unsigned installer. I suggest everyone to join the civil disobedience. If you don't, you'll soon find out you can't run your programs.
User mode code is a different scenario. There are three possibilities:
- unsigned code pops up with a big warning 'your pc will explode' or something like that when you try to run it.
- signed code does not need a cross signed certificate. Any CA can include the code signing oids and voila. This displays as yellow but the CN is extracted as the publisher name.
- Finally EV certificates give you 'instant reputation' i.e. no orange warning. The difference is entirely audit related and the OIDs you may include. The crypto is identical to normal certs.
This I'm fine with. I understand Microsoft wanting to protect their kernel and the user experience and I'm on board with that but I like the fact that windows has traditionally been a very open system. It is a real shame it is heading the other way.
I haven't developed windows drivers for years though, or used windows as my daily machine for years either (it was Linux at home, windows at work, now Linux for both).
"...(it was Linux at home, windows at work, now Linux for both)."
That's my ideal plan but for many reasons it's been a long road for me and others I know.
In controlled environments where the outcomes are either narrow or clearly defined then money can be thrown at the problem to ensure that Linux penetration is 100%. Unfortunately, I'd hate to count the number of times I've seen this objective come unstuck for many reasons, thus an annoying residual of Windows installations remain.
Generally, it's not the lack of Linux applications that's the problem but more a mixture of compatibility issues brought about by a diverse range of hardware types and vintages thereof combined with either a lack of Linux drivers or the poor performance thereof - for instance the nVidia driver and Linux's native NTFS driver that's now old and leaves much to be desired (yes, I'm aware of Paragon's NTFS diver and I'm hoping that it will, in part, improve matters).
Also, ordinary users still have significant difficulties in installing Windows apps in WINE not to mention getting printer drivers to work. I don't know how many times I've heard "I tried to install the CD that came with the printer and it didn't work".
It would be nice to see the Linux community spend more time on these compatibility issues for if we could solve many of them then we'd see an upsurge in Linux usage on the desktop.
Even I haven't eliminated Windows completely. As far as I'm concerned this is now a high imperative given that Windows has morphed from being an independent operating system into a fully-fledged functional appendage of the Microsoft Corporation.
I was wondering about that. Every update when it says it's unsigned I get really nervous and triple-check the source and monitor traffic during the install.
They mentioned ProcessExplorer, but actually linked to TaskExplorer. I think it was a referencing mistake. TaskExplorer is what they meant, another independent program.
On Mac it's significantly more locked down and judging from recent comments by Tim Cook they still aren't happy with it. Presumably they see iOS as the gold standard internally and would love to make OS X work the same way, but can't without breaking too many apps. The recent stance taken by the judge on Epic v Apple re: Gatekeeper will certainly push them further in the lockdown direction :(
On OS X Intel the operating system will basically refuse to run unsigned code unless you know an ever-shifting series of magic undocumented cheat codes. You have to do weird things like hold down certain keys then use the right click context menu to open unsigned apps, you need magic CLI commands to disable notarization checking, you have to go into the system preferences window to enable drivers to be approved and then reboot etc. The UX is atrocious and gets worse all the time - it's barely acceptable even for developers. That's for usermode. Kernel mode drivers are dead now, more or less.
On OS X ARM unsigned code will not run. Period, end of story. The magic cheat codes are gone. All code must be notarized, which is a server-side approval process of the type Microsoft only use for kernel drivers.
There are a few silver linings to all this. One is that getting a cert isn't actually that hard. You need a credit card, basically. It's not like getting an EV cert where you need a company and for a CA to verify the corporate identity. Likewise their "notarization" process is not a manual app store like review, it's fully automated and is mostly just checking that the app is well structured and properly signed. It probably does other things like checking you aren't using internal APIs, and they presumably archive all the binaries they notarize so they can go back in time to investigate malware and so on. But it's not being used for political or commercial purposes, at this time.
1) on Windows entails a significant security downgrade, as you cannot just pick custom kernel extension only, with validation by the user. That might however not be important, depending on your threat model.
For 2), it’s borderline impossible to get a driver signing cert for macOS nowadays for individuals, it’s easier on Windows.
Kexts are not deprecated in general-- only kexts that use deprecated KPIs are deprecated. (The page you link is the list of deprecated KPIs.)
The net effect of this: if something can be done using a System Extension rather than a kernel extension, you'll get deprecation warnings if you try to do it with a kernel extension. Kernel extension points that have not been replaced yet are still valid, will still be signed if used, and will still run on current versions of macOS.
This is one of those areas where the government should step in and require MS and others an opt-in back door where you can turn off secure boot but still use windows uninhibited for hobby and experimental purposes. Similar to the way we need more laws for right-to-repair.
"Since Sysinternals were bought by Microsoft many years ago and the tools are distributed directly via Microsoft, such tools are unlikely to have an issue being signed."
It's a damn shame that Russinovich sold out to Microsoft as that broke Sysinternals' independence. It seems clear to me that Sysinternals was getting a bit too clever for Microsoft's liking and by buying Russinovich out then meant that it could control the process. Likewise, Process Explorer is being silenced for similar reasons, and denying certificates is obviously cheaper.
> This is because most CAs won't issue EV certificates to individuals, even if those individuals happen to have detailed knowledge of cryptography and all the pkcs
.
Honestly the majority of Orgs don't have these chops. There's really no go way to proof anyone.
I think the rationale for Orgs is just that they have more to lose.
A brief history of the process for those not following it. Originally for kernel-mode drivers, you needed a code signing certificate cross signed by Microsoft's root. This means that the certificate follows a chain up to a standard CA _and also_ one Microsoft use to approve that CA to issue kernel-mode certificates. It was not sufficient to have a certificate capable of signing code, even with MS' OIDs for that.
Then, around Windows 10 I think, Microsoft announced that one would need to acquire an EV certificate. You would then be required to submit the driver package via sysdev.microsoft.com and after spending time in Ballmer's Brewery, it would come out signed by Microsoft.
It was technically possible to use the old mechanism at this stage too, provided the end user did not have UEFI secure boot enabled. IF secure boot were enabled, the kernel would: a) if the driver was signed pre-Win10, accept it, b) if it was signed post win-10 RTM date and by Microsoft, accept otherwise reject.
Thus the only mechanism to realistically get your driver working on all Windows out of the box is to submit via sysdev. You can't realistically ask users to disable secure boot, even if this is entirely possible on all x86 motherboards.
Finally, the cross signed roots expire soon and I think some already have. Microsoft have decided that this mechanism will now be retired, and all drivers must be signed via sysdev from now on. You still require an EV certificate as well, to sign the package.
This is a bit of a mixed bag. On the one hand, Microsoft have repeatedly signed the shim maintained by redhat in order to allow Linux distributions to boot directly on secure boot-enabled hardware (UEFI binaries also go through this process and always have). Microsoft have their keys in the default keychain because they bothered to be involved in the process, unlike linux companies like Redhat. So on the one hand, they're being quite friendly to open source.
On the other hand, the push to EV certs rules out individual developers like myself[1]. I could register a company but... that entails effort and expense for a hobby project. And now hobbyist projects like this run the risk of being rejected by MS.
I mostly believe this is an attempt to reduce the number of code signing cert leaks that result in people writing malware, and lock down the Windows kernel a bit more, but still. It is a shame.
[1] This is because most CAs won't issue EV certificates to individuals, even if those individuals happen to have detailed knowledge of cryptography and all the pkcs.