I'd like to have a better understanding of how sandboxing and multiprocess work.
First, is multiprocess and sandboxing actively supported?
Is Servo tested with the "-M -S" options?
What's the status of the sandbox?
Is there any reasons for these options to not be turned on by default?
Do we want t
Hi,
On Wed, Jun 22, 2016 at 09:57:22AM -0700, Bobby Holley wrote:
> In a bit more detail, there are basically 3 ways to manage CI:
> (1) The mozilla-inbound model (land possibly-untested stuff, run CI
> post-commit, perform backouts and close tree as necessary)
> (2) The bors/homu model (run the
This sounds like a useful optimization; and it can be applied to the system
after it is set up.
I believe that the autoland model works like this anyway, though I'm not
100% sure.
But we could do this on the Servo side.
-Manish Goregaokar
___
dev-serv
The constellation is the process manager; as far as Servo is concerned,
there is only one constellation in the entire universe.
What we have is one-process-per-Origin, since iframes within the same
Origin are able to share JavaScript objects directly.
On Tue, Aug 2, 2016 at 12:46 AM Paul Rouget
> First, is multiprocess and sandboxing actively supported?
I tested this right before the nightly release, and it was working
fine and didn't seem to have bad performance. Note that you can run -M
or -M and -S, but not -S by itself (which doesn't make sense). Also
note that -M and -S probably don
We're currently testing -M but not -M -S, e.g. see:
https://github.com/servo/saltfs/blob/master/buildbot/master/files/config/steps.yml#L46
I don't think there's any great reason for not testing sandboxing as well
as multiprocess. We're testing multiprocess for Mac and Linux, not Windows
as multip
On Tue, Aug 2, 2016 at 6:47 PM, Jack Moffitt wrote:
>> First, is multiprocess and sandboxing actively supported?
>
> I tested this right before the nightly release, and it was working
> fine and didn't seem to have bad performance. Note that you can run -M
> or -M and -S, but not -S by itself (whi
It's not a stupid question :) I actually think we should gather all script
and layout threads together into one process. Maybe two, one for
high-security sites and one for all other sites.
Patrick
On Aug 2, 2016 6:47 PM, "Paul Rouget" wrote:
> On Tue, Aug 2, 2016 at 6:47 PM, Jack Moffitt wrote
Each process is a sandboxing boundary. Without security as a concern
you would just have a single process. A huge next step is to have a
second process that all script/layout threads go into. This however
still leaves a bit of attack surface for one script task to attack
another. How many processes
I can think of one advantage right now: by having script and layout in
separate processes, a compromised script thread doesn't automatically give
an attacker the ability to produce malformed display lists that draw
outside the tab boundary.
On Tue, Aug 2, 2016, 20:43 Jack Moffitt wrote:
> Each p
10 matches
Mail list logo
