I’m not sure what kind of peripherals the article talks about, but I’ve had a lot of weird crashes with ASUS MB onboard feature that provides RGB lightning to various fans and whatever. I may misremember the details; it was 6 or so years ago when I encountered that, but their AsIO driver was an abomination of engineering. Not only was it a god driver that allowed users to mess with arbitrary memory and MSRs from userspace, it managed to somehow mess up SMBus and cause random lockups.
Guess there’s plenty of other hardware companies that aren’t producing better software.
Assuming you want to preserve the same functionality of drivers, how would giving the userspace RGB controller driver the same set of tools (usually fun things like physical memory RW) change anything?
Windows 11 was the time to do so, and they missed it. I'd bet it was assessed, briefly, as too big a change to be acceptable if old devices were not going to be compatible.
Win 11 already invalidated quite a few relatively modern systems. As far as I know, it was an arbitrary threshold which has not materialized into an actual hardware requirement to run. As a joke, someone installed Win11 on a computer with a Pentium 4.
Microsoft did break backwards compatibility with some drivers (packed stuff that relied on being able to write to executable sections, for instance) w/ HVCI and then with some other stuff (for instance, drivers using push+ret for obfuscating function calls + some exception handling related machinery some virtualization based obfuscators used) with KCET.
With that being said virtualization based security is not mandatory, though compliance is needed for signing new drivers (note: this is funky too and some drivers will do HVCI-noncompliant things when it’s disabled, like some anticheat drivers hooking #PF to more efficiently catch unsigned code execution in HVCI-free scenario). I think next backwards compatibility breaking move will be enabling SMAP.
The solution would be simply to add a warning as a temporary measure preferably in red text and in a way that would scare the average user. This warning should be accompanied by a call to action urging users to contact the device manufacturer and ask them to release a new driver. Then companies would have no choice but to either create a new driver that runs in user space or be constantly inundated with support requests from customers.
Unfortunately that doesn't work, when a warning sits between a user and the application they want to run, they will always say yes, and then someone has to clean all those browser toolbars.
I’m not sure what kind of peripherals the article talks about, but I’ve had a lot of weird crashes with ASUS MB onboard feature that provides RGB lightning to various fans and whatever. I may misremember the details; it was 6 or so years ago when I encountered that, but their AsIO driver was an abomination of engineering. Not only was it a god driver that allowed users to mess with arbitrary memory and MSRs from userspace, it managed to somehow mess up SMBus and cause random lockups.
Guess there’s plenty of other hardware companies that aren’t producing better software.
Yes, the time to cage drivers into userspace is long time overdue, and it isn't for lack of userspace drivers API.
Apparently Microsoft still can't play an Apple move, in the quest to do so.
Assuming you want to preserve the same functionality of drivers, how would giving the userspace RGB controller driver the same set of tools (usually fun things like physical memory RW) change anything?
Just like microkernels, or macOS for that matter, where all drivers are being pushed out of the kernel.
Outside desktop, they are pretty much around on embedded RTOS, and the Switch.
Windows 11 was the time to do so, and they missed it. I'd bet it was assessed, briefly, as too big a change to be acceptable if old devices were not going to be compatible.
Win 11 already invalidated quite a few relatively modern systems. As far as I know, it was an arbitrary threshold which has not materialized into an actual hardware requirement to run. As a joke, someone installed Win11 on a computer with a Pentium 4.
Technically the hardware threshold is sort of real for making virtualization based security usable and useful.
Exactly, it was the whole set of virtualisation based security that is optional in Windows 10, and was made compulsory on Windows 11.
Microsoft did break backwards compatibility with some drivers (packed stuff that relied on being able to write to executable sections, for instance) w/ HVCI and then with some other stuff (for instance, drivers using push+ret for obfuscating function calls + some exception handling related machinery some virtualization based obfuscators used) with KCET.
With that being said virtualization based security is not mandatory, though compliance is needed for signing new drivers (note: this is funky too and some drivers will do HVCI-noncompliant things when it’s disabled, like some anticheat drivers hooking #PF to more efficiently catch unsigned code execution in HVCI-free scenario). I think next backwards compatibility breaking move will be enabling SMAP.
The solution would be simply to add a warning as a temporary measure preferably in red text and in a way that would scare the average user. This warning should be accompanied by a call to action urging users to contact the device manufacturer and ask them to release a new driver. Then companies would have no choice but to either create a new driver that runs in user space or be constantly inundated with support requests from customers.
Unfortunately that doesn't work, when a warning sits between a user and the application they want to run, they will always say yes, and then someone has to clean all those browser toolbars.
That would be yet another reason to complain about Windows 11 though, unfortunately.