|
|
Created:
6 years, 7 months ago by jln (very slow on Chromium) Modified:
6 years, 7 months ago CC:
chromium-reviews, agl, jln+watch_chromium.org, mdempsky Base URL:
svn://svn.chromium.org/chrome/trunk/src Visibility:
Public. |
DescriptionLinux sandbox: disallow fork() and *kill for ASAN
Treat ASAN like non-ASAN and disallow fork() and *kill there as well.
BUG=367986
R=jorgelo@chromium.org
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=267292
Patch Set 1 #Patch Set 2 : Remove unused function. #Patch Set 3 : Rebase #Messages
Total messages: 12 (0 generated)
Jorge, Alexander, PTAL! Alexander: I don't think there is any reason to treat ASAN in a special way, is there? Or is it creating threads without pthread? If the glibc flags are not appropriate for ASAN, I can relax things a bit there and simply forbid anything without CLONE_THREAD | CLONE_VM.
On 2014/04/30 01:22:04, jln wrote: > Jorge, Alexander, PTAL! > > Alexander: I don't think there is any reason to treat ASAN in a special way, is > there? > > Or is it creating threads without pthread? If the glibc flags are not > appropriate for ASAN, I can relax things a bit there > and simply forbid anything without CLONE_THREAD | CLONE_VM. LSan calls clone() with "CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_UNTRACED".
On 2014/04/30 15:10:06, earthdok wrote: > On 2014/04/30 01:22:04, jln wrote: > > Jorge, Alexander, PTAL! > > > > Alexander: I don't think there is any reason to treat ASAN in a special way, > is > > there? > > > > Or is it creating threads without pthread? If the glibc flags are not > > appropriate for ASAN, I can relax things a bit there > > and simply forbid anything without CLONE_THREAD | CLONE_VM. > > LSan calls clone() with "CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_UNTRACED". So does TSan, though I'm not sure in which situations (and whether they happen in Chrome).
On 2014/04/30 15:21:16, earthdok wrote: > On 2014/04/30 15:10:06, earthdok wrote: > > On 2014/04/30 01:22:04, jln wrote: > > > Jorge, Alexander, PTAL! > > > > > > Alexander: I don't think there is any reason to treat ASAN in a special way, > > is > > > there? > > > > > > Or is it creating threads without pthread? If the glibc flags are not > > > appropriate for ASAN, I can relax things a bit there > > > and simply forbid anything without CLONE_THREAD | CLONE_VM. > > > > LSan calls clone() with "CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_UNTRACED". > > So does TSan, though I'm not sure in which situations (and whether they happen > in Chrome). Ahh, you do CLONE_VM without CLONE_THREAD, correct? I suppose I didn't test LSAN correctly. In which situation does it do that? Always, not only after a leak is detected? If you don't always use CLONE_THREAD, then I can't really block *kill in LSAN because of the NSS bug.
lgtm % finding the right set of flags.
On 2014/04/30 15:50:17, jln wrote: > On 2014/04/30 15:21:16, earthdok wrote: > > On 2014/04/30 15:10:06, earthdok wrote: > > > On 2014/04/30 01:22:04, jln wrote: > > > > Jorge, Alexander, PTAL! > > > > > > > > Alexander: I don't think there is any reason to treat ASAN in a special > way, > > > is > > > > there? > > > > > > > > Or is it creating threads without pthread? If the glibc flags are not > > > > appropriate for ASAN, I can relax things a bit there > > > > and simply forbid anything without CLONE_THREAD | CLONE_VM. > > > > > > LSan calls clone() with "CLONE_VM | CLONE_FS | CLONE_FILES | > CLONE_UNTRACED". > > > > So does TSan, though I'm not sure in which situations (and whether they happen > > in Chrome). > > Ahh, you do CLONE_VM without CLONE_THREAD, correct? I suppose I didn't test LSAN > correctly. In which situation does it do that? Always, not only after a leak is > detected? Always. The leak detection routine is run on this special thread. The reason is that it must have direct access to parent's address space (for performance) but not be part of the same thread group (because otherwise ptrace would not work). > If you don't always use CLONE_THREAD, then I can't really block *kill in LSAN > because of the NSS bug.
On 2014/04/30 16:01:14, earthdok wrote: > On 2014/04/30 15:50:17, jln wrote: > > On 2014/04/30 15:21:16, earthdok wrote: > > > On 2014/04/30 15:10:06, earthdok wrote: > > > > On 2014/04/30 01:22:04, jln wrote: > > > > > Jorge, Alexander, PTAL! > > > > > > > > > > Alexander: I don't think there is any reason to treat ASAN in a special > > way, > > > > is > > > > > there? > > > > > > > > > > Or is it creating threads without pthread? If the glibc flags are not > > > > > appropriate for ASAN, I can relax things a bit there > > > > > and simply forbid anything without CLONE_THREAD | CLONE_VM. > > > > > > > > LSan calls clone() with "CLONE_VM | CLONE_FS | CLONE_FILES | > > CLONE_UNTRACED". > > > > > > So does TSan, though I'm not sure in which situations (and whether they > happen > > > in Chrome). > > > > Ahh, you do CLONE_VM without CLONE_THREAD, correct? I suppose I didn't test > LSAN > > correctly. In which situation does it do that? Always, not only after a leak > is > > detected? > Always. The leak detection routine is run on this special thread. The reason is > that it must have direct access to parent's address space (for performance) but > not be part of the same thread group (because otherwise ptrace would not work). Ok, thanks for the explanation. I could actually still EPERM the NSS case by EPERMing any clone without CLONE_VM. But do you need *kill to work on something else than the main process? For instance, does the LSAN "thread", signal the main thread group?
On 2014/04/30 16:09:26, jln wrote: > On 2014/04/30 16:01:14, earthdok wrote: > > On 2014/04/30 15:50:17, jln wrote: > > > On 2014/04/30 15:21:16, earthdok wrote: > > > > On 2014/04/30 15:10:06, earthdok wrote: > > > > > On 2014/04/30 01:22:04, jln wrote: > > > > > > Jorge, Alexander, PTAL! > > > > > > > > > > > > Alexander: I don't think there is any reason to treat ASAN in a > special > > > way, > > > > > is > > > > > > there? > > > > > > > > > > > > Or is it creating threads without pthread? If the glibc flags are not > > > > > > appropriate for ASAN, I can relax things a bit there > > > > > > and simply forbid anything without CLONE_THREAD | CLONE_VM. > > > > > > > > > > LSan calls clone() with "CLONE_VM | CLONE_FS | CLONE_FILES | > > > CLONE_UNTRACED". > > > > > > > > So does TSan, though I'm not sure in which situations (and whether they > > happen > > > > in Chrome). > > > > > > Ahh, you do CLONE_VM without CLONE_THREAD, correct? I suppose I didn't test > > LSAN > > > correctly. In which situation does it do that? Always, not only after a leak > > is > > > detected? > > Always. The leak detection routine is run on this special thread. The reason > is > > that it must have direct access to parent's address space (for performance) > but > > not be part of the same thread group (because otherwise ptrace would not > work). > > Ok, thanks for the explanation. I could actually still EPERM the NSS case by > EPERMing any clone without CLONE_VM. But do you need *kill to work on something > else than the main process? For instance, does the LSAN "thread", signal the > main thread group? The LSan "thread" does not send any signals. It may send ptrace requests though.
On 2014/04/30 16:25:15, earthdok wrote: > The LSan "thread" does not send any signals. It may send ptrace requests though. And the main thread group doesn't signal it either? How does it die? Moreover, doesn't this "thread" get started before the sandbox? This would completely break the sandboxing model. Does LSAN run with the sandbox at all? I thought not. In which case all is good and I'd proceed with the current patch. We should simply keep in mind that LSAN would silently disable the sandbox if it start its "thread" before the sandbox is engaged.
On 2014/04/30 16:29:15, jln wrote: > On 2014/04/30 16:25:15, earthdok wrote: > > > The LSan "thread" does not send any signals. It may send ptrace requests > though. > > And the main thread group doesn't signal it either? No. > How does it die? It runs until it's done, and then exits. > Moreover, doesn't this "thread" get started before the sandbox? This would > completely break the sandboxing model. It starts when leak detection is triggered, which is just before process termination. Moreover, the main thread group is suspended until the special thread finishes its work. > Does LSAN run with the sandbox at all? I thought not. Not currently, but hopefully will at some point in the future. > In which case all is good > and I'd proceed with the current patch. We should simply keep in mind that LSAN > would silently disable the sandbox if it start its "thread" before the sandbox > is engaged.
On 2014/04/30 16:43:07, earthdok wrote: > On 2014/04/30 16:29:15, jln wrote: > > On 2014/04/30 16:25:15, earthdok wrote: > > > > > The LSan "thread" does not send any signals. It may send ptrace requests > > though. > > > > And the main thread group doesn't signal it either? > No. > > > How does it die? > It runs until it's done, and then exits. > > > Moreover, doesn't this "thread" get started before the sandbox? This would > > completely break the sandboxing model. > It starts when leak detection is triggered, which is just before process > termination. Moreover, the main thread group is suspended until the special > thread finishes its work. > > > Does LSAN run with the sandbox at all? I thought not. > Not currently, but hopefully will at some point in the future. Ok, thanks! I'll land the change as-is then. When we want to try and make LSAN work with the sandbox, I'm happy to poke certain holes, as long as we have a way to detect LSAN (detecting dynamically - via environment for instance - is fine).
Message was sent while issue was closed.
Committed patchset #3 manually as r267292 (presubmit successful). |