4 ms·

I thought that, unlike apps, drivers needed a Microsoft signature, not just any root CA's signature? Was that not the case?

adamson 9y ago
I don't think that was ever true (at least in the last decade)
- throwaway613834 9y ago
  What about MCVR on this page?http://www.davidegrayson.com/signing/ http://www.davidegrayson.com/signing/
khedoros1 9y ago
I think that it will allow you to install the drivers, but have an extra red pop-up with a warning about unsigned drivers. To get a clean, professional-looking installation, you've got to have a primary signature that chains down to a trusted root CA and also a cross-signature, which is a Microsoft cert used to sign the code's root CA's certificate.
- throwaway613834 9y ago
  What about MCVR on this page? It seems to be more than just for the dialog box? http://www.davidegrayson.com/signing/ http://www.davidegrayson.com/signing/
  - khedoros1 9y ago
    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.
    - throwaway613834 9y ago
      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.
      - khedoros1 9y ago
        > 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.

adamson 9y ago

I don't think that was ever true (at least in the last decade)

throwaway613834 9y ago
What about MCVR on this page?http://www.davidegrayson.com/signing/ http://www.davidegrayson.com/signing/

khedoros1 9y ago

I think that it will allow you to install the drivers, but have an extra red pop-up with a warning about unsigned drivers. To get a clean, professional-looking installation, you've got to have a primary signature that chains down to a trusted root CA and also a cross-signature, which is a Microsoft cert used to sign the code's root CA's certificate.

throwaway613834 9y ago
What about MCVR on this page? It seems to be more than just for the dialog box? http://www.davidegrayson.com/signing/ http://www.davidegrayson.com/signing/
- khedoros1 9y ago
  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.
  - throwaway613834 9y ago
    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.
    - khedoros1 9y ago
      > 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.