Bug 1104619 (sb-audio)

[meta] Sandboxing improvements when audio playback & recording are remoted

NEW
Unassigned

Status

()

defect
P3
normal
Rank:
20
5 years ago
4 months ago

People

(Reporter: gcp, Unassigned)

Tracking

(Depends on 2 bugs, {meta})

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Comment hidden (empty)
(Reporter)

Updated

5 years ago
(Reporter)

Updated

4 years ago
Assignee: nobody → gpascutto
Component: Audio/Video → Audio/Video: MSG/cubeb/GMP
Component: Audio/Video: MediaStreamGraph → Audio/Video: cubeb
Rank: 20
Priority: -- → P2
Should this be tracked by sandboxing? It looks like this could fix Bug 1259283.
Whiteboard: sb?

Updated

3 years ago
Whiteboard: sb? → sblc1
Moving to sblc2 because this is currently not blocking enabling seccomp on nightly. However, it will allow us to revert the patch landed as part of Bug 1259508, once audio is remoted.
Whiteboard: sblc1 → sblc2
(Reporter)

Updated

3 years ago
Blocks: 1285525
Discussed this with :gcp over irc, he is not currently working on it.
Assignee: gpascutto → julian.r.hector
We should have a look at how chromium does this before proceeding. Also don't hesitate to ask any question, this is full of gotchas.

This is the code on the host side (= Chrome process for us): https://cs.chromium.org/chromium/src/content/browser/renderer_host/media/audio_input_renderer_host.cc?sq=package:chromium&rcl=1474529952&l=349
Flags: needinfo?(julian.r.hector)
Thank you very much.

So far my approach is to remote the cubeb API found in cubeb.h. But I am currently dealing with a threading issue since I created a sync protocol. It seems that the Send method is called from a thread it can't block on.

I probably have to do something similar to the LockAndDispatch [1] that :gcp did on PCameras, which makes this slightly more complicated.

[1] http://searchfox.org/mozilla-central/rev/8910ca900f826a9b714607fd23bfa1b37a191eca/dom/media/systemservices/CamerasChild.cpp#188
Flags: needinfo?(julian.r.hector)
(Reporter)

Updated

3 years ago
Blocks: 1309098
Assignee: julian.r.hector → nobody

Updated

2 years ago
Whiteboard: sblc2 → sblc3
Whiteboard: sblc3 → sblc3, sbmc3

Updated

2 years ago
Whiteboard: sblc3, sbmc3 → sblc5

Updated

2 years ago
Depends on: 1346665

Updated

2 years ago
No longer depends on: 1284816

Updated

2 years ago
Keywords: meta

Updated

2 years ago
Whiteboard: sblc5

Updated

2 years ago
Alias: sb-audio
Priority: P2 → P3

Updated

2 years ago
Component: Audio/Video: cubeb → Security: Process Sandboxing

Updated

2 years ago
Depends on: 1382448
Retitling this bug to match what its new purpose seems to be.  The audio remoting discussed in previous comments seems to now be covered in bug 1362220.
Depends on: 1126437, 1213998
Summary: Sandboxing support for audio playback & recording → Sandboxing improvements when audio playback & recording are remoted
Depends on: 1405091
Summary: Sandboxing improvements when audio playback & recording are remoted → [meta] Sandboxing improvements when audio playback & recording are remoted
You need to log in before you can comment on or make changes to this bug.