derekbruening
commented
10 years ago From derek.br...@gmail.com on May 17, 2010 17:33:07
in r333 I added a pretty good step toward best-effort isolation, given that we can't easily swap the whole segment selector. I'm lowering the priority of any further isolation to Low as it will be handled on an as-needed basis.
My r333 change adds isolation of two data structures:
1) PEB isolation
- Use a private PEB copy. Since we can't create a segment descriptor from user mode for Win64, giving up on swapping TEB: we'll have to swap individual fields there. For PEB, if everyone accesses via TEB, we can have a copy of that and swap with one store. Have to swap on every clean call and client event cb.
- We just do a shallow copy for now until we hit an issue w/ deeper fields that are allocated at our init time. Anything allocated by libraries after our init here will of course get its own private deep copy.
- We do not intercept private libs calling NtQueryInformationProcess to get info.PebBaseAddress (not exposed in any WinAPI routine) but I tried to have a client use that method to get the real app PEB and it turns out the query syscall goes and reads the TEB pointer to the PEB!
- We need private PEB in place whenever call client code, so to get the app's PEB I added an API routine (since NtQueryInformationProcess doesn't work).
- Add options to control the existing heap isolation, which was added by me in my original private loader code (-privload_privheap), and to control peb isolation (-private_peb)
2) TEB->FlsData isolation
- With isolation of the TEB->FlsData field added, all the errors stemming from transparency violations (on tests/malloc.exe) go away.
- Because TEB->FlsData is more expensive to isolate (persistent and varies per thread), the code to swap it is only invoked when a client with dependent libraries is present
Labels: -Priority-Medium Priority-Low
From derek.br...@gmail.com on January 16, 2010 12:35:09
xref private Windows loader issue #157 for now we're not providing perfect isolation and are assuming that nothing terribly intrusive will be done to the TLS (TEB, PEB) shared w/ the app's dlls. ideally we would could create our own segment and private copies of the TEB and PEB and have our private dlls use that instead of the system's per-thread segment. it's not clear we could emulate everything done to initialize them, and there may be issues with trying to initialize fields owned by the loader or other components we don't need. would we leave such fields uninitialized, or would we call LdrInitializeThunk and assume the only global side effects will be limited to the (private) PEB?
we'd create our own segment via NtSetLdtEntries (xref PR 208009). though this is only available on 32-bit Windows kernels (xref PR 212905) and patchguard may prevent even a kernel driver from adding new gdt entries on 64-bit? also xref issue #108 .
Original issue: http://code.google.com/p/dynamorio/issues/detail?id=249