I'm not clear on the difference between a driver and a kernel module in the Windows world. As far as I could tell, we were talking about installing drivers, and the "Signature requirements for it to just work" seem to list just a SHA-2 cert from a trusted root CA for installing drivers, even for Windows 10.
Maybe there's something I'm misunderstanding here. I've set up Windows codesigning, but it was according to the specifications of the Windows devs; most of my own work has been in Linux.
Yeah I can see why you're confused about the terminology. I'm not aware of anything called a "kernel module" in the Windows world (despite the name on that page). They're all just called "drivers". If they're for devices, they're called "device drivers"; if they're for filtering the file system, they're called "file system filter drivers", etc. It seems like on that page they're referring to the actual binary as the "kernel module" and to the overall package as the "driver package" (not all of which is executable kernel-mode code).
The distinction being made across the columns is between installing the driver (i.e. putting it in the right directory and setting up the settings and everything so that it can be loaded) versus actually loading the driver (i.e. telling the kernel to execute the code immediately). They require different permissions. You need to satisfy both for your driver to run, and you can see that MCVR is a requirement for loading a driver on newer Windows versions, i.e. you need trust from Microsoft, not just the user.
Now as some people are pointing out, Microsoft also has a user-mode driver framework which doesn't seem to have the requirements of the kernel module. (On the other hand, it exposes more limited functionality.) So if you're writing a user-mode driver then you might not need trust from Microsoft. But that's not what I generally mean when I say "driver"... to me "driver" implies kernel-mode, or at least the union of the
two. It certainly doesn't just refer to the user-mode kind.
> I'm not aware of anything called a "kernel module" in the Windows world
I ran into that last night. It was implied in the MS documentation that all kernel-mode drivers in Windows were "loadable kernel modules".
Anyhow, thank you for the clarification. That's kind of the direction I was thinking, but it's nice to see a more concrete description.
I'd also suspected that there was a distinction similar to "kernel-mode driver" and "user-mode driver", but all that I saw in Microsoft's documentation when I was looking last night were the descriptions of the differences between bus, device, and filter drivers.
Reading with a clearer head now, I found some more clarifying material. VxD was the earliest Windows driver model, supplanted close to 20 years ago by WDM. On top of that is the WDF, which sounds like it was first introduced just after WDM, and complementing it. And that's the one that has a separate Kernel-Mode Driver Framework and User-Mode Driver Framework.
From my background, "driver" always implied kernel-mode, unless specifically specified. I mean, I can write a user-mode driver on a Raspberry Pi (or what have you) to communicate with external hardware over the IO pins, but it's a clearly different process than writing a kernel module. For example, I could write user-mode driver code in Python, and don't have to worry about the internal workings of the kernel.
> From my background, "driver" always implied kernel-mode, unless specifically specified.
Right, so it seems correct to say that you cannot load a driver using just a custom root certificate. You need it trusted by a root certificate from Microsoft, which (assuming that is correct) means much of this thread is wrong.
