You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 .
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:
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)
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
Fibers (Windows user-mode lightweight threads) swap TEB fields when they swap contexts. They do this via regular memory copies, so there's nothing special to help us out there. But, we should look at the fiber TEB switch to see the full list of fields and sub-fields we'd need to copy for full isolation.
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
The text was updated successfully, but these errors were encountered: