Comment by MatejKafka
18 hours ago
How exactly do you propose to sandbox drivers running in kernel space? Do you even know how drivers work? (I'm guessing no, based on this comment)
18 hours ago
How exactly do you propose to sandbox drivers running in kernel space? Do you even know how drivers work? (I'm guessing no, based on this comment)
There are people working on this problem honestly. The general solution 10 years ago was a micro kernel. Today, I’m not sure. The linux model is starting to look dated, with similar problems elsewhere. Modern hardware design looks less and less like classic textbook design, with all kinds of random chips having direct memory access to memory the cpu uses on some shared bus. Where even things like on board blue tooth chips can become attack vectors on the system.
There was a good keynote on the topic 5 years ago By Timothy Roscoe
https://www.usenix.org/conference/osdi21/presentation/fri-ke...
Agree with all of those points and there are some partial solutions (IOMMU, userspace drivers, virtualization,...), but we're still quite far from being able to safely connect untrusted hardware and load its driver without effectively giving it privileged access.
The User-Mode Driver Framework is a thing. Most plug-in devices do not need (or have) a kernel-mode driver.
Yes, but unless all 3rd party drivers can run in userspace (which is not really feasible), Microsoft needs to give vendors the option to install a kernel driver, at which point a vendor can always decide to ship a kernel driver and bypass any restrictions.
Imo, the only thing Microsoft can meaningfully do here from their side is threaten LG with pulling all their drivers if they keep doing this.
Drivers still need to pass certification & get signed. Microsoft does get to reject them.
I can't imagine the group doing this validation is sufficiently manned/funded; it's a cost centre, and the effects of cutting it don't show up for years.
1 reply →
Microsoft has a program to do static and dynamic analysis of drivers... not a sandbox, but better than nothing. Of course, wonky drivers plus wonky hardware can still do bad things (io-mmu can help, a bit).
The problems tend to be in the userspace software that's also installed with the driver. Sometimes there's also some pretty derpy stuff where the driver wants to talk to the userspace software but there's no validation/verification and that opens up a big hole.
First of all, drivers don't have to run in kernel space. Do you know that? I'm guessing no, based on your comment.
Second, we're not talking about the drivers per se, as those aren't what shows you ads, it's the configuration software and accompanying crapware. Did you get that? I'm guessing no, based on your comment.
Third, there are capability-based kernels, microkernels, drivers that are allowed into as restricted bytecode, IOMMU, and several other layers of security. Do you know that? I'm guessing no, based on your comment.
To answer in a more constructive way:
No mainstream desktop OS tries very hard to sandbox drivers. Some drivers on both Windows and Linux (not very familiar with Mac) can be implemented as userspace drivers, as long as the performance hit is acceptable, but for many devices (e.g., graphics drivers), you need a kernel driver to get reasonable performance.
Therefore, if your OS supports loading 3rd party binary drivers (Windows do, Linux technically does as well, but tries to make them hard to use in practice), it cannot really refuse to load kernel drivers and only allow userspace ones without breaking a lot of machines.
Even if you have a userspace driver, the device may still get DMA access to RAM. IOMMU is a thing, but due to backwards compatibility, the driver chooses whether to enable IOMMU protection for the specific device on Windows.
If you're willing to write your own microkernel and bootstrap its driver ecosystem from scratch, your claims would be reasonable. With current desktop OS architecture, not really.
As for the accompanying software, there is a good explanation in another comment of all the valid use cases it has (printer dialogs, audio interface configuration,...). LG abusing that to show ads is primarily LG's problem.
Read sibling comments to get answers to all your (non)questions.
Strange how you didn't read them then, based on your rude and false response to my comment.
You don't have to counterbalance every useful sentence with a toxic message.
You do, when you're responding to "Do you even know how drivers work? (I'm guessing no, based on this comment)". I'm merely giving them back their toxic comment right back.
2 replies →