If it is anything like Linux, those drivers are likely unsigned by the packager and they are a vulnerability for secure boot and your UEFI bootloader.
Like if someone did the same type of attack as the XZ compression utility in Linux recently; where a benign looking file is modified and another is equally altered within the package so that the total file size does not change. That kind of attack is not possible with a signed kernel module/driver.
That is the only thing I can think of that would tie all of these elements together. They could all be accessing something in kernel space using an unsigned driver.
If it is anything like Linux, those drivers are likely unsigned by the packager and they are a vulnerability for secure boot and your UEFI bootloader.
Like if someone did the same type of attack as the XZ compression utility in Linux recently; where a benign looking file is modified and another is equally altered within the package so that the total file size does not change. That kind of attack is not possible with a signed kernel module/driver.
That is the only thing I can think of that would tie all of these elements together. They could all be accessing something in kernel space using an unsigned driver.
How is using a compromised userspace library not possible with a signed kernel module?
That aside, if the events would unfold similarly, the software requiring to be signed would be, in fact, signed.
An awfully stupid comment TBF. As if you desperately tried to defend MS. EDIT: Sorry, that was just my irritation.