1214947 - [meta] B2G sandbox file broker device enablement

Status: RESOLVED WONTFIX

(Core :: Security: Process Sandboxing, defect)

Description

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

Bug 930258, as landed, uses filesystem access brokering (and, by extension, unwhitelists open() and similar) only on the B2G emulator, because physical hardware tends to need model-specific whitelist entries, often for device files.  Fully testing one physical device is not the simplest task, and testing *all* of them is a much larger task, but it can parallelize well.  

Bug 1199866 (specifically the part about /dev/kgsl) will block at least flame-kk and maybe other Qualcomm-based devices; I think that's the only known breakage like that.

For functionality testing, the general workflow is something like:

1. Run with MOZ_SANDBOX_VERBOSE set or comment out the check on the "Rejected" message in SandboxBrokerClient::DoCall to get log messages for failures.  Some of those are harmless (the files might not exist, or the code might not actually need them); look for broken/degraded functionality or failed tests.  open() flags might need to be decoded with /usr/include/asm-generic/fcntl.h

2. To get more information on why a file is being opened, the tedious but effective approach I've been using is to add a policy rule with the SandboxBroker::CRASH_INSTEAD flag, rebuild, ./build.sh buildsymbols, redo the test case, pull the crash dump, and use minidump_extract (which has to be built by hand; see bug 943142) locally.  Also, follow logcat for the JS stack dump if applicable.

2a. Sadly there aren't too many alternatives.  Normal stack unwinding can't cross the SIGSYS handler frame on ARM (but see bug 968531).  A debugger will break on SIGSYS at every intercepted syscall, so doing `x/s $r0` and `continue` (maybe gdb can automate that?) also gets tedious after a while — and if it's an automated test, attaching the debugger at the right time can be hard.

3. File a bug with the information and block bug 1121295; we've been doing this even if it doesn't seem likely that the whitelist entry can be removed.

I've mostly done manual testing — load a page/app with WebGL, try recording/playing video/audio, etc. — but the Gaia UI tests and/or mochitests might provide more coverage in ways that are meaningful here.  

The other concern here is about performance, especially about graphics, and especially about use cases like opening /dev/genlock every frame on (some?) Qualcomm hardware; adding extra syscalls and context switching to a hot path like that could be problematic.  But I don't think we ever had numbers about this one way or the other, just speculation; this needs more testing.

Comment 1

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

B2G-specific sandboxing bugs are WONTFIX.  (I'm reasonably sure these bugs don't have implications for other platforms, but comment if I missed something.)