5 ms·
This is Windows-only. The code claims to be userland but relies on kernel middleware. That is interesting, because the driver seems to be signed. If you've neve
by snagglegaggle 7y ago
This is Windows-only. The code claims to be userland but relies on kernel middleware. That is interesting, because the driver seems to be signed. If you've never looked at Windows kernel stuff, you'd probably be surprised at:
1) How much it looks like *nix.
2) How hard it is to actually use your own code.
> Windows Server 2016 systems must have secure boot disabled.
That's no good.
- mehrdadn 7y ago> How hard it is to actually use your own code. What do you mean by this? It's easy enough with test-signing. Just use SignTool sign to sign your binary. Then sc create to create the service for the driver, and sc start to start it as usual. > How much it looks like 'nix. Also not sure what you mean by this either... to me there's a world of difference between Windows and 'nix kernel development.
- snagglegaggle 7y agoTest signing isn't meant to be used on a real system. You're intended to have an entirely separate test cluster or at least test machine. There are usability downsides to this, many of them cosmetic, but one major one is you need to disable secure boot. In some cases (this may have changed) you could only enable test signing for the next boot meaning you had to constantly keep re-enabling it. Overall very user hostile, and it leaves one with the impression they don't want you to run your own code or let other people run your code without paying protection money. For the other part... go look at the driver documentation. The names are different but the patterns are all the same except for a few places.
- mehrdadn 7y agoOkay then I don't get it. What even is the point of secure boot when your entire goal is to run arbitrary kernel mode code? You're effectively always running in test-signing mode on Linux -- your entire goal is to be able to run your own modules, which is what test-signing mode does. And if you want to be in that situation, you can permanently enable it with bcdedit; there's no need to constantly toggle it. If your complaint is that you have to cough up $$$ to have your driver be trusted by other users' machines, yeah, I'm happy to rant about that issue, but that's not an issue with the "difficulty" of the process. That's like saying it's hard to use a Lamborghini because it's too expensive. As for the names and patterns... idk, it's hard for me to see what's similar, except that both systems have file systems, both have handles/descriptors, etc... which is hardly an interesting point. Everything from the way you hook I/O to the way syscalls are handled to the quality of the documentation is vastly different on each system.
- snagglegaggle 7y ago> What even is the point of secure boot when your entire goal is to run arbitrary kernel mode code? Err, it's code I wrote, or code I am likely to be familiar with? My issue isn't with the feature of driver signing but its application. I can choose to be in test signing mode on Linux or not, and if I am, it doesn't gimp the system in arbitrary ways. Look again, Windows is like a black box over a rewritten Unix kernel. It's kind of funny. It took a while for it to click.
- mehrdadn 7y ago> My issue isn't with the feature of driver signing but its application. I can choose to be in test signing mode on Linux or not, and if I am, it doesn't gimp the system in arbitrary ways. I don't know what "gimp the system in arbitrary ways" means. I've been running Windows in test-signing mode for years with no problem. Microsoft doesn't officially bless it, but that doesn't exactly matter in any material way.