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

[Sebastian Lackner]

On 21.01.2016 17:22, Jacek Caban wrote:
> On 01/21/16 16:58, Jacek Caban wrote:
>> On 01/21/16 16:04, Sebastian Lackner wrote:
>>> On 21.01.2016 15:43, Jacek Caban wrote:
>>>> On 01/19/16 17:06, Alexandre Julliard wrote:
>>>>> Jacek Caban <jacek at codeweavers.com> writes:
>>>>>
>>>>>> All such solutions require changes in both Chrome and Wine, which makes
>>>>>> it tricky to decide on a solution. What's your opinion?
>>>>> My concern is not just about hooking the system calls, it's what happens
>>>>> once they are hooked. Sebastian said that hooks inside the Ldr*
>>>>> functions don't work right. I'm worried that supporting this properly
>>>>> would require that our internal code paths follow the Windows ones
>>>>> closely, which is neither feasible nor desirable.
>>>>>
>>>>> This could of course also be changed in Chrome so that it could deal
>>>>> with the way Wine's ntdll is implemented, but that would probably be
>>>>> more intrusive.
>>>> It's hard to discuss what Sebastian reports without understanding the
>>>> problem. For what I know, his variant of patches exposes way more
>>>> hookable calls than it should. It's not a secret that on Windows Nt*
>>>> functions will not call any other exported functions. This is an
>>>> implementation detail that I don't consider too internal to follow. The
>>>> fact that those hooks may be called recursively with Sebastian's patches
>>>> makes me think that it's the most likely reason of the problems.
>>> Could you please point out where you think my patchset doesn't match
>>> Windows behavior / leads to recursive calls which should not occur?
>> I looked deeper in your patchset and the one occur that I thought was
>> there was my mistake.
> 
> Actually no, it was a valid example. Here is a stack that has two syscalls:
> 
> NtOpenFile -> FILE_CreateFile -> nt_to_unix_file_name_attr ->
> RtlAllocateHeap -> HEAP_FindFreeBlock -> HEAP_CreateSubHeap ->
> NtAllocateVirtualMemory
> 
> Cheers,
> Jacek
> 

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.

Could we maybe generate more complex thunks which automatically keep track of
nested Nt* calls (for example, by counting somewhere in the TEB structure)?
Its pretty complex to get this right without any separation in ntdll or help of
the compiler.

Best regards,
Sebastian