Address space clobbers during fork() (was Re: Extending /proc/*/maps)

Ryan Johnson ryan.johnson@cs.utoronto.ca
Thu Apr 21 19:37:00 GMT 2011


On 21/04/2011 3:15 PM, Corinna Vinschen wrote:
> On Apr 21 17:40, Chris January wrote:
>>> Second, I don't know who maps locale.nls, but it happens *very* early
>>> in the life of the process, long before gdb can talk to it. Using
>>  From what I can gather from http://www.alex-ionescu.com/part1.pdf
>> and Reactos source code I believe it's mapped by MmCreatePeb, called
>> from PspCreateProcess, called from NtCreateProcess{Ex}. It doesn't
>> look like mapping it in advance would help (if that was even
>> possible), but it may be possible (but risky) to map it somewhere
>> else, update the pointers in the PEB, and then unmap the original.
> I scanned the above PDF, but I can't gather where the pointer to
> locale.nls is stored in the PEB from that description.
None of the definitions I've seen for struct _PEB includes an obvious 
pointer to locale.nls.

As a general rule, I'm extremely wary of messing with addresses set by 
syscalls, because we don't know how much in-kernel state is tangled up 
with them. Doubly so since the relevant information may very well be 
64-bit only and therefore inaccessible to cygwin.

Further, looking at the disassembly of RtlGetLocaleFileMappingAddress, I 
see a whole lot more than a simple PEB check going on, including calls to:
ntdll!RtlIsDosDeviceName_U
ntdll!LdrSetDllManifestProber
ntdll!ZwInitializeNlsFiles
ntdll!ZwUnmapViewOfSection

There are also several references to the global variable 
ntdll!NlsAnsiCodePage, and an atomic op for good measure:
lock cmpxchg qword ptr [ntdll!RtlNtdllName+0x1cc58],rcx

Granted, a lot of the above probably handles the uninitialized case, but 
it seems like playing with fire to mess with this.

$0.02
Ryan



More information about the Cygwin-developers mailing list