| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a followup to an earlier change (r38266) which did most of the
warning-related cleanup. This one just flips the flag, and fixes some
new warnings that crept in during the window while the flag was off.
Second try, now with some libpng fixes.
BUG=34160
Review URL: http://codereview.chromium.org/1320011
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42700 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
| |
Compiled locally and on trybots but failed on builder?!
This reverts commit r42688.
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42689 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This is a followup to an earlier change (r38266) which did most of the
warning-related cleanup. This one just flips the flag, and fixes some
new warnings that crept in during the window while the flag was off.
BUG=34160
Review URL: http://codereview.chromium.org/597023
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42688 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
| |
Make tcmalloc compatible with the seccomp sandbox by avoiding making direct system calls from within tcmalloc.
BUG=38973
TEST=none
Review URL: http://codereview.chromium.org/1294001
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42667 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
|
|
|
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
|
