TBPL should be able to usefully report on sandbox violations

RESOLVED FIXED in mozilla30

Status

()

Core
Security
RESOLVED FIXED
5 years ago
4 years ago

People

(Reporter: jld, Assigned: jld)

Tracking

({meta})

Trunk
mozilla30
ARM
Gonk (Firefox OS)
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Assignee)

Description

5 years ago
When we have targets in TBPL that use seccomp sandboxing, there will eventually be test runs that fail due to sandbox violation.  We need to ensure that the responsible developer, and the sheriffs, can get enough information about the failure to take appropriate action.

In particular, tossing a line into logcat and exiting, so that the test times out five minutes later, is probably not that.

It seems to me that we should be able to handle SIGSYS (caused by a sandbox failure in reporter mode) the same way we'd handle a SIGSEGV from a memory error.
(Assignee)

Updated

5 years ago
Duplicate of this bug: 932107
(Assignee)

Comment 2

5 years ago
Making the Breakpad reporter handle SIGSYS turns out to be fairly simple.  There's a bit of subtlety in making it coexist with the existing reporter handler, and dealing with signal handler return being different from the other crash signals, but nothing huge.
Assignee: nobody → jld
(Assignee)

Updated

5 years ago
Depends on: 942407
(Assignee)

Updated

5 years ago
Depends on: 943774
(Assignee)

Updated

5 years ago
Depends on: 945330
(Assignee)

Updated

5 years ago
Depends on: 945498
(Assignee)

Updated

5 years ago
Depends on: 945504
(Assignee)

Comment 3

5 years ago
There are enough sub-bugs now that having patches on this bug itself seemed potentially confusing.
Keywords: meta
(Assignee)

Comment 4

4 years ago
It's not ideal yet (see bug 942290), but it seems to be “useful”.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
You need to log in before you can comment on or make changes to this bug.