What is the purpose of PE conversion of *.sys drivers?

[Jinoh Kang]

On 7/4/22 05:19, Stefan Dösinger wrote:
> Hi,
> 
> I am not directly involved in any of those, but here are my best guesses:
> 
>> Am 03.07.2022 um 21:33 schrieb Jinoh Kang <jinoh.kang.kr at gmail.com>:
>>
>> 1. Accurate emulation of Windows userspace. As kernel drivers run in kernel
>> mode, a syscall interface does not make sense at all.
> 
> Not all of them. See e.g. winspool.drv, which is something applications can link against. Might have inherited the "wrong" file ending somewhere, but it is mostly a regular DLL otherwise.

I'm aware that a few drivers (e.g. some *.drv files) are actually userland modules mostly as a relic from Windows 9x days.
Right now, my main focus are on _kernel_ drivers, i.e. the ones directly loaded alongside NTOSKRNL (or, on winedevice.exe in case of Wine).
Apologies if it wasn't clear enough.

> 
>> 2. Wow64 support. Note that 64-bit Windows does not support running 32-bit
>> drivers. I don't necessary see a significant value in supporting 32-bit
>> binaries on a Wow64 wineprefix, but others may have different opinion.
> 
> I think there are two things affecting this:
> 
> *) Application-provided drivers (DRM etc) still need a Windows-ish environment. They run in the same space our .drv's run. Afaics those drivers can also link against our .sys modules, e.g. the dinput tests contain a driver that links against hidclass.sys.

The thing is, the environment of NT Kernel/Executive differs greatly from that of the Win32 userspace, so we already kind of fail when we don't have proper IRQL / POPF / privileged instruction semantics.

That said, IMHO fakedll may not matter much unless the driver is doing something really weird (beyond hotpatching) with those modules or reading from that PE file directly.
I can see how one could want to do that with NTOSKRNL.EXE or HAL.DLL, but other PnP drivers / filters less so (modulo hotpatching, of course).

> 
> *) aarch64 and x86_64 (on mac) still need a non-trivial syscall thunk for TLS registers. I am not sure if there is any kind of TLS support in a .drv in the Windows kernel though.

I see how thunk for transition of thread register would be necessary for anything that interact with custom drivers, although it doesn't have to be in a form of a syscall (if a custom thunk would be simpler to implement than a full unixlib split).
Also, the "TLS" in NT Kernel is actually per-cpu rather than per-thread.

> 
> *) We might want to run 32 bit DRM drivers on 64 bit even if Windows doesn't support that. We can currently load old 32 bit safedisk 2 drivers and want to retain that. Windows solved this problem by providing a rewrite of the safedisk drivers. I don't know how they handle kernel DRM modules on aarch64.

I think more work would be involved in translating 64-bit calls to 32-bit I/O requests (FastIO or IRP), but a basic support would be an intereseting idea.

Ideally the device driver shall be integrated with host, with Wine merely acting as a translation layer.  Not sure if it could happen, though...

> 
> I think it is the combination of those points why we want to have a windows-y kernel environment and not take the host environment 1:1.
> 

Thank you very much for your thoughtful response!

-- 
Sincerely,
Jinoh Kang