mirror of
https://github.com/mozilla/gecko-dev.git
synced 2024-11-24 21:31:04 +00:00
272d93bb18
Background: When 32-bit types are passed in registers on x86-64 (and probably other platforms?), the function call ABI does not specify the contents of the upper half, and the Linux kernel syscall ABI appears to have the same behavior. In practice, the upper half is usually zero (or maybe sign-extended from the lower half), because 64-bit operations aren't cheaper than 32-bit, and 32-bit operations zero-extend their outputs; therefore, this case usually doesn't happen in the first place, and any kind of spill or register move will zero the upper half. However, arbitrary values are possible, and a case like this has occurred with the Firefox profiler using `clock_gettime`. (This paragraph is applicable to x86-64 and ARM64; other 64-bit architecutures may behave differently.) But the Chromium seccomp-bpf compiler, when testing the value of a 32-bit argument on a 64-bit platform, requires that the value be zero-extended or sign-extended, and (incorrectly, as far as I can tell) considers anything else an ABI violation. With this patch, when that case is detected, we use the `SIGSYS` handler to zero-extend the problematic argument and re-issue the syscall. (It would also be possible to just ignore the upper half, and that would be faster, but that could lead to subtle security holes if the type used in `bpf_dsl` is incorrect and the kernel really does treat it as 64-bit.) Differential Revision: https://phabricator.services.mozilla.com/D143964 |
||
|---|---|---|
| .. | ||
| apps | ||
| certverifier | ||
| ct | ||
| mac/hardenedruntime | ||
| manager | ||
| nss | ||
| rlbox | ||
| sandbox | ||
| .eslintrc.js | ||
| generate_certdata.py | ||
| generate_mapfile.py | ||
| moz.build | ||
| nss.symbols | ||