This enables hardware owners to specify custom kernel driver signing requirements, enabling kernel mode code to run without having to submit it to Microsoft for signing.
The backside fingerprint reader could even be used as an input device on some models for scrolling, or pulling down/up the notification bar. Great for scrolling through content or swiping through screens without having to cover your display for gesture input: https://www.androidauthority.com/miss-rear-fingerprint-scann...
This is one of the big things I miss from my Pixel 5a; it was so nice to be able to unlock the phone and pull down the notifications bar with one hand. There's a lot I like about the Pixel 8 Pro I replaced it with, but that's one thing I miss.
There was a "healthy" phone called the Bloc Phone which had the screen in Black & White by default but allowed you to use the fingerprint on the back at any time to give you a few minutes of colour when (say) looking through your camera roll. Really cool idea.
Exactly--this plus the usability original commenter communicated made this why I did so much work to keep my Pixel 3 alive for so long. I still think about the rear fingerprint sensor after a Pixel 3 -> pixel 6 -> S21 Ultra -> S24 Ultra journey, and further how much fun i had back in the ROM + kernel + modding + undervolting days.
Ironically, some devices (Pixel 9 at least) have now added a tiny little touch sensor exactly where the fingerprint reader used to be - it doesn't read the fingerprint, but you can regain this functionality by mapping taps to actions.
I can't even imagine why they decided to keep the fingerprint sensor on the front but add a whole separate sensor on the back.
Are you talking about the feature "Quick Tap" in the settings where you can double tap the back? There's no sensor for that, they just use the accelerometer to detect that input. It's been incredibly unreliable for me.
Yeah! I use that quite a lot on my Pixel 4a. It's particularly useful to close the system quick settings, since I can just scroll once instead of 4 times x)
Even before the virtualization-based security feature was introduced this has been the Hyper-V architecture, on server and client SKUs. The management OS is referred to as the "parent partition" or "root partition," and it runs on top of the hypervisor: https://learn.microsoft.com/en-us/virtualization/hyper-v-on-...
Kernel drivers have to be verified by the driver verifier to pass Windows Hardware Qualification Labs certification and get signed with the Windows signing key that lets them load without warnings. There are fewer outside kernel drivers today, though, because plugging random peripheral cards into PC buses is no longer a big thing.
This is true for certification, which is mandatory for Server OS, distributing through Windows Update, or certain classes of drivers such as anti-malware or biometric authentication, but you can still submit drivers to Microsoft for "attestation signing" that will load without warnings on desktop OS without having to run them through the testing suite.
In any case, running the certification tests does not provide runtime protection for drivers running in kernel mode, as demonstrated by CrowdStrike. Only Windows 10 started introducing hardware virtualization-based isolation of kernel components (to provide isolation of security subsystems, not runtime checks to prevent crashes): https://learn.microsoft.com/en-us/windows-hardware/design/de...
Yet drivers that have passed Windows Hardware Qualification Labs certification have had blue screens. Also, Microsoft hands out Windows kernel driver signing keys to anyone who pays them. You don't need to have a driver go through the Windows Hardware Qualification Labs to be able to sign it with a key signed by Microsoft.
> They actually advise OEMs not to install this second key by default ("Secured Core" PCs), and some vendors have followed the advice, such as Lenovo. Resulting in yet another hoop to install non-MS OSes.
True, 3rd party not trusted by default is a "Secured-Core PC" requirement, but so is the BIOS option for enabling that trust [0]. On my "Secured-Core" ARM ThinkPad T14s it's a simple toggle option.
> Even recently, a Windows updated added a number of Linux distributions to the Secure Boot blacklist, resulting in working dual boot systems being suddenly cripped. Of course, _ancient_ MS OSes are never going to be blacklisted.
Actually they are in the process of blacklisting their currently used 2011 Windows certificate, i.e. the Microsoft cert installed on every pre-~2024 machine, also invalidating all Windows boot media not explicitly created with the new cert. It's a manually initiated process for now, with an automatic rollout coming later [1].
It'll be very interesting to watch how well that's going to work on such a massive scale. :)
> True, 3rd party not trusted by default is a "Secured-Core PC" requirement, but so is the BIOS option for enabling that trust
As I said, yet another increase in the number of hops for no reason.
Before you say anything else: until this you could install _signed_ Linux distributions without even knowing how to enter your computer's firmware setup. Now you can't.
The trend is obviously there. First, MS forced Linux distributions to go through arbitrary "security" hoops in order to be signed. Then, MS arbitrary altered the deal anyway. Even mjg59 ranted about this. And the only recourse MS offers to Linux distributions is to pray MS doesn't alter the deal any further.
Maybe at no point they will make it impossible on x86 PCs, but they just have to keep making it scary enough.
And in the meanwhile keep advertising how WSL fits all your Linux-desktop computing needs. While at the same time claim they have nothing against opensource.
> Actually they are in the process of blacklisting their currently used 2011 Windows certificate
No, they are NOT in the process, and that is precisely what I was referring to. They have not even announced when they are going to even start doing the process. All you quoted is instructions to do it manually. So I'll believe it when I see it.
And besides, just clearing the CMOS is likely to get you a nice ancient DBX containing only some grub hashes on it, and the Windows MS signature on DB. Not so much luck for the MS UEFI CA signature, as discussed above. So "recovery" will be trivial for Windows, not so much for anyone else..
> I think drivers are going to be the biggest PITA for ARM-based PC users for the first couple years — for example, Google Drive doesn't work for that reason.
Google Drive does ship with Arm64 drivers, and patching the platform check out of the installer gets them installed just fine (40 84 f6 74 08 -> 40 84 f6 90 90).
It's so ridiculous. You ever wanted Explorer's "details" file list view to have horizontal blank space between rows so rather than selecting the nearest item you could just click through the list into a blank void and select nothing? Yeah, that's what the default setting is now. For a list view. It's like making up unusable space between cells in Excel for no reason.
In any case, you're free to remove Microsoft's certificates and enroll your own.
reply