Lxdrv POC, limitations?

[fpqc]

Hi there, Alex. I haven't seen a proper blogpost or talk by you about LxDrv, and I took a look at the code, but I'm totally clueless about Windows driver development.

Two quick questions:

1.) If I compile the POC driver, won't I have a ton of trouble installing it because it's not signed (do I need to enable test-signing and boot in debug mode or something)?

2.) Also, question about limitations: Is there any reason why the new driver interface couldn't be used to create a shim driver with a custom libgl in lxss and have it send the Windows-compatible ioctls (probably driver-dependent) to the Windows graphics drivers? From what I could glean, the proprietary Linux graphics drivers work by having a user-mode library (nvidia-libgl or fireglrx-libgl) communicate directly by ioctls with a binary blob loaded as a kernel module and exposed by an interface just like this.

Reason why I'm asking is that CUDA is one of the top feature requests on uservoice, as is support for things like ifconfig, both of which would need more device driver exposure. Wondering if you'd be willing to speculate if this kind of thing will be used to implement CUDA on WSL or just be part of their solution for getting ifconfig and networking tools working.

[ionescu007]

1. Yes, you'll have to enable test signing and the rest. This is described online and also on the SimpleVisor page. There's an assumption people playing with it have some low-level experience :)

My BlueHat presentation in November will talk about the interface I'm using, so you'll have a nice set of slides to go along with it.

2. Yes, this is exactly what it can be used for, and likely what MSFT is doing with it as well internally. Lxcore.sys for example has an export DevGfxInitialize....