| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This means changes to the sandbox won't have to be committed twice, to
both trees.
This is a retry of r57921, which was committed with git-svn and failed
to remove the "seccomp" directory. This caused problems when trying
to "svn checkout" to the same location, and the change was reverted.
This time I will use SVN to commit the change.
BUG=none
TEST=smoke test of running chromium with --enable-seccomp-sandbox
Review URL: http://codereview.chromium.org/3225010
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@58184 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
copy
This means changes to the sandbox won't have to be committed twice, to
both trees.
BUG=none
TEST=smoke test of running chromium with --enable-seccomp-sandbox
Review URL: http://codereview.chromium.org/3249003
TBR=mseaborn@chromium.org
Review URL: http://codereview.chromium.org/3245011
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@57933 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This means changes to the sandbox won't have to be committed twice, to
both trees.
BUG=none
TEST=smoke test of running chromium with --enable-seccomp-sandbox
Review URL: http://codereview.chromium.org/3249003
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@57921 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
complicated by the fact that in Seccomp mode, we can only ever call
sigreturn(). But in order to eventually support sigaction(), we want to
be able to also call rt_sigreturn().
We solve this problem by rewriting the signal stack frame from an RT
signal frame to a legacy frame. Fortunately, this part of the signal
frame is stable between kernel versions. The unstable part (i.e. extended
registers such as FP, MMX, SSE, ...) is always identical in both in both
types of signal frames.
None of these complications exist on x86-64 and it is relatively
straight-forward to enable support for the system call. The only
difficulty lies in the fact that its calling conventions are somewhat
different from "normal" system calls. So, we have to handle rt_sigreturn()
from within the syscallWrapper() and the segv() handler and cannot write
it in C code.
TEST=ad hoc testing until we have support for sigaction(). Then we can add a unittest
BUG=37728
Review URL: http://codereview.chromium.org/1739011
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@45774 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We previously assumed that no signals would ever be enabled in the sandbox
and thus there was no way to trick the trusted thread into executing potentially
untrusted code.
In an attempt to lift this restriction, this changelist modifies the trusted
thread so that
- it has an invalid stack pointer at all times. Any attempt to handle a
signal would result in the kernel trying to push a signal stack, which
would immediately result in a SEGV and then terminate the application.
- all signals are blocked while outside of trusted code. If a signal is
triggered, it either gets handled on one of the sandboxed threads (for
asynchronous signals), or it results in the application getting terminated
by the kernel (for synchronous signals).
This changelist is difficult not only because eliminating all uses of the
stack pointer requires some very careful assembly coding, but more importantly
because we have to restore signals after we enter seccomp mode.
As sigprocmask() is a restricted system call, the only way to restore the
signal mask is by calling sigreturn() with a suitably tweaked signal
stack frame. While the first couple of bytes of the signal stack frame are
well-defined and unlikely to change, the entire signal stack frame is not
documented as part of the stable ABI. The exact format depends on the number of modified CPU registers (e.g. SSE, MMX, floating point, ...)
The only way for us to get a valid signal stack frame is to trigger a
signal, and to create a (possibly adjusted) copy of the signal frame. We
obviously have to do this _before_ we block all signals upon entering
trusted code.
The two places where this needs to happen is upon start of the sandbox when
launching the initial trusted thread, and upon any call to clone().
BUG=37728
TEST=Run chrome and verify that /proc/$PID/status shows the correct signal mask for trusted threads. The latter can be identified with strace.
Review URL: http://codereview.chromium.org/1594040
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@45055 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
| |
is going to be skewed slightly, as calling gettimeofday() by itself also
takes a little bit of time. But it should be good enough to allow us to see
where we have performance bottlenecks.
TEST=none
BUG=none
Review URL: http://codereview.chromium.org/997009
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@41905 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
were observed on some machines (in particular in 32bit mode).
- Some more changes to avoid calling into glibc when we can make a direct
system call, instead. These particular call sites were unlikely to cause
any problems. But it makes the code easier to audit if we avoid all
unnecessary calls into glibc.
- In 64bit mode, gettimeofday() is handled by vsyscalls and tends to be cheap.
In 32bit mode, it is just a regular system call. Some users rely on being
able to call gettimeofday() at a very high rate (up to thousands of
consecutive calls). Recognize this system call pattern and optimize for it.
- Add debugging option that allows us to warn about expensive system calls.
In many cases, these warnings can then be used to optimize the sandboxed
application.
- Fix compilation on newer versions of gcc.
- Changed the x86-32 version of the code that we use when intercepting
system calls. Previously, we would use CALL to jump to the set of
instructions that we had relocated. But we made the mistake of allowing
relocation of instructions that reference %esp. This doesn't work, as
CALL modifies the stack. We now avoid using CALL and instead jump
directly. On x86-32 that requires the use of a PUSH/RET combination as
there is no 32bit wide JMP instruction.
The x86-64 version of the code was already written in a way that would
avoid this particular problem.
(I would like to thank Craig Schlenter for his exceptional detective
work in tracking down the root cause of this bug!)
- For debugging purposes, injected a really small library (less than 4kB)
and discovered that some of our memory map manipulations implicitly
relied on mappings to be at least two pages long. Fixed the code that
made this incorrect assumption.
- For really small libraries, the runtime linker can choose a different
more compact layout. Our computation of the ASR offset did not know how
to deal with that. Fixed by explicitly looking for a ".text" segment
instead of looking for a PT_DYNAMIC section.
- Closed a file descriptor that we kept open longer than needed.
- Removed some unused code.
- Added copyright headers
TEST=tested on i386 and x86-64
BUG=36133
Review URL: http://codereview.chromium.org/661438
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@40900 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
internal. This ensures
that the linker won't complain about IP relative addressing for symbols that could be overridden at
run-time.
- avoided using "g" register constraints, as there has been a report of some versions of GCC
erroneously generating code that is no longer position independant when this constraint is used.
- removed the old code that fork()'s a child to try to extend mappings of libraries at run-time. This
code always was somewhat fragile and caused a measurable performance penalty when the sandbox was
started. Replaced with code that remapped just the very first page. This can actually be done in a
running process without disrupting the use of the libraries.
- added a special case for the instrumentation code allowing it to deal with jumps between the VDSO
and VSyscalls even if the instructions would normally not be eligible for interception as they are IP
relative. After making this change, we can again find sufficiently large code snippets to rewrite them
successfully. This is only a concern on x86_64.
- fixed a bug that would erroneously look for IP relative addressing on x86_32. It doesn't exist for
that architecture.
TEST=none
BUG=http://code.google.com/p/chromium/issues/detail?id=18337
Review URL: http://codereview.chromium.org/306036
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@29726 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(Patch by Markus)
This allows the fast path to use read()/write() instead of recvmsg()/sendmsg()
which is much cheaper for the Seccomp sandbox.
Also, fixed minor seccomp sandbox issues discovered by this change.
BUG=19120
ISSUE=164373
http://codereview.chromium.org/177049
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@25518 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
http://code.google.com/p/seccompsandbox/
Make the seccomp sandbox dependant on the --enable-seccomp-sandbox flag
Review URL: http://codereview.chromium.org/165310
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@23087 0039d316-1c4b-4281-b951-d872f2087c98
|
