Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[windows] TLS/TEB/PEB isolation for private dll copies #249

Open
derekbruening opened this issue Nov 27, 2014 · 2 comments
Open

[windows] TLS/TEB/PEB isolation for private dll copies #249

derekbruening opened this issue Nov 27, 2014 · 2 comments

Comments

@derekbruening
Copy link
Contributor

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

@derekbruening
Copy link
Contributor Author

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)
  1. 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

@derekbruening
Copy link
Contributor Author

From bruen...@google.com on January 22, 2013 12:53:53

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant