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 was a good keynote on the topic 5 years ago By Timothy Roscoe
https://www.usenix.org/conference/osdi21/presentation/fri-ke...
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.
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.
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.
I'm not surprised that the driver got approved, especially if the previous versions already had some user UI and this update "just" added the ads. What I would hope now is for MS to either pull the updated driver or ask LG to roll the change back themselves, possibly under the thread of pulling their drivers altogether (iirc they done that with other companies in the past).
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.
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.
Though there is a limit to how much you can effectively sandbox a driver for most devices. They do have a point even if they made it badly. I know you listed some methods but they don't generalize to arbitrary devices very well.
>Though there is a limit to how much you can effectively sandbox a driver for most devices. They do have a point even if they made it badly. I know you listed some methods but they don't generalize to arbitrary devices very well.
Likely not, but the rarer cases could always be exceptions.
Most devices, screens, printers, mice, audiocards, etc should not have to go through this, at least not for basic functioning.
Which is why I like e.g. "class compliant" devices for example, whereas the configurations can be managed directly from the OS with no third party driver loaded. Some of those do come with the custom proprietary driver, but for most I don't even bother installing it.