[PATCH 1/3] winebuild: Added support for entry points generated in runtime.

[Sebastian Lackner]

On 22.01.2016 03:13, Erich E. Hoover wrote:
> On Jan 21, 2016 9:41 AM, "Sebastian Lackner" <sebastian at fds-team.de> wrote:
>> ...
>> In this case it shouldn't matter (as far as I know NtOpenFile isn't
> intercepted
>> by the Chromium Sandbox), however when thinking more carefully about it,
> heap
>> functions could indeed be problematic. What we theoretically need is two
> sets of
>> them, user mode calls are supposed to go through NtAllocateVirtualMemory,
> but
>> kernel mode calls not. I'll do some more testing myself, so far I haven't
> found out
>> which thunks exactly introduce the randomness in the Chromium sandboxing
> code.
>> ...
> 
> Maybe this is being overly simplistic, but we do have both Zw* and Nt*
> entry points. It could make sense to use Zw* internally and route all the
> external calls through the thunks (Nt*).
> 
> Best,
> Erich
> 

I already thought about that, but on Windows both Nt* and Zw* exports point to
the same function. Sooner or later we might find an application which relies
on this. Of course we could still use Zw* names internally only, but like any
other solution, its a huge amount of effort to check all calls manually.
Especially things like heap management functions are used both in "user mode"
and "kernel mode".