Process per tab discussion.
Johnny Stenback
This is a summary of a set of discussions that started between a set of
individuals in person at the Firefox summit, and briefly continued
recently in a private email thread. The people involved in the
discussions so far were Robert O'Callahan, Benjamin Smedberg, Boris
Zbarsky, Brendan Eich, Damon, Sicore, Jim Mathies, and Robert Strong.
Here's roughly what's been discussed so far:
Early on in the discussions it was suggested that the first step should
be to enable profile sharing so that multiple processes can share a
Necko cache, cookies, prefs, etc. But that's actually obviously wrong,
and it would also be a tediously hard process; the Chrome docs says that
we shouldn't allow maliciously compromised processes from directly
accessing the network to violate same-origin restrictions. Chrome
actually proxies all I/O back to the master process where it could be
same-origin checked etc. (Well, we don't currently know how that
currently works in Chrome either, since foreign-origin IFRAMEs are
hosted in the same renderer process as the container, but whatever.)
Having necko only in the master process would be largely benefitial to
us as the startup time and memory footprint cost of NSS is fairly
substantial, and having to take that hit per child process would be less
than ideal.
Another thought along these lines was to use shared memory segments to
share the data between processes, and use pipes primarily for smaller
control data, and that would probably be a good IPC optimization to
leverage here.
One thing that obviously needs to be shared by the different processes
is preferences. It would probably make the most sense to have the child
processes ask the parent process for preference values. And this is
actually very simple to implement w/o modifying the pref service API.
So a good early step would be to itemize the resources and APIs that a
Gecko content window needs that sandboxing will need to proxy over to a
trusted process, and figure out the best way to do that. If we're smart
enough we could also leverage that to get profile sharing, for example
by allowing a new trusted process (Prism say) to locate an
already-running process and proxy its resource requests to it.
Thanks to Adam Barth and Collin Jackson, we have less to worry about wrt
cross-origin window joining. We already prevent window.open() from
returning references to other windows unless they're same origin.
Furthermore, same-origin content code could run in the same process.
Chrome can do this, and actually has a set of complex and tweakable
policy settings where you can run all tabs from the same site (defined
by eTLD) in the same process. By default it will also cap the number of
content processes and thus can end up using the same process for
multiple sites, which is obviously not ideal. Chrome has one exception
to the general rule here, and that is that opening about:blank, setting
the new windows opener to null and then loading a URL in the new window
will create a new process, even if the origin of the code that's opening
the window and the loaded URL are from the same origin. This is a
workaround for sites to force another page to load in another process
(process cap presumably still taken into account here).
Another thing that's been discussed/thought about, is the huge issue of
what the extension model should look like. The big issue is of course
what to do when an extension in the chrome process wants to touch
content. After initial pessimism about this issue it seems we could
actually preserve most of our current extension model. Here's what we're
thinking:
-- when chrome JS takes a reference to a content JS object, it gets wrapped
-- no references from content JS to chrome JS (or any other process's
content JS) are allowed
-- the wrapper proxies calls over to the content JS object via IPC. If a
parameter reference is disallowed by the above restriction, data is
copied or an exception is thrown
-- those calls run on timeouts. If the content process fails to respond
quickly, we throw (in a way that extensions can catch and retry, or
whatever).
To prevent races in content from being observable by chrome,
-- while chrome JS is running to completion, maintain a set of "locked"
content processes
-- the first time that running script needs to touch a content process,
lock it. This requires the content process to acknowledge the lock and
suspend normal reflow, script execution etc; it waits synchronously for
the unlock, serving only chrome requests.
-- when chrome JS finished running to completion, release all locks
-- note that you still need timeouts on all chrome->content requests
because the content might be compromised and acknowledge the lock and
then hang
That should work and let most extensions work without compromising the
separation architecture. We could offer additional facilities for
running extension code in the context of the content process, for
performance, but that would be dangerous since that code could not be
trusted but extension authors could trust it anyway. Maybe we could
define a new class of sandboxed extensions that are restricted to a
particular domain and run without privilege, that would take care of
some of those needs.
If we want to get away w/o locking we could maybe have a
.runScriptInWindow() API for extentions which need to perform
synchronous script execution, but that would be an entirely new model
for extensions to use. The current run-to-completion model needs to
continue to hold true.
There are a bunch of other design issues, like how to handle the
rendering of subprocesses, how to handle plugins, and so on. Some of
those are actually unsolved by Chrome so far.
Benjamin Smedberg
> same-origin checked etc. (Well, we don't currently know how that
> currently works in Chrome either, since foreign-origin IFRAMEs are
> hosted in the same renderer process as the container, but whatever.)
> Having necko only in the master process would be largely benefitial to
> us as the startup time and memory footprint cost of NSS is fairly
> substantial, and having to take that hit per child process would be less
> than ideal.
Note that this is more complicated because e.g. we allow CSS loading. It's
not clear to me that Chromium actually prevent cross-origin network loads at
the process layer at all.
> Another thought along these lines was to use shared memory segments to
> share the data between processes, and use pipes primarily for smaller
> control data, and that would probably be a good IPC optimization to
> leverage here.
To elaborate: schlepping large hunks of data such as images and network
buffers can eat up pipe buffers very quickly, and typically don't need to be
*written* by the tab process, only *read*. Using shared memory for these
buffers could protect the parent process from memory corruption while
avoiding some complex pipe heroics.
> Thanks to Adam Barth and Collin Jackson, we have less to worry about wrt
> cross-origin window joining. We already prevent window.open() from
See http://dev.chromium.org/developers/design-documents/process-models
and
http://dev.chromium.org/developers/design-documents/multi-process-architecture
for some details about Chromium's multi-process architecture.
> There are a bunch of other design issues, like how to handle the
> rendering of subprocesses, how to handle plugins, and so on. Some of
> those are actually unsolved by Chrome so far.
If I'm reading the docs correctly (I haven't read the code in detail),
Chromium currently has the child process render to a pixel buffer. The child
process doesn't have a window handle or process UI events directly. This
means that you have to proxy all events (mouse moves, clicks, etc) from the
outer process, performing coordinate translation, IME input translation, etc
as you go.
It sounds a lot easier, as a prototype, to actually have the child process
as a native window with its own event loop; this has some definite
drawbacks, but it would be a good start to get it working in this manner.
Another thing I think we need to measure/discuss is the kinds of caches and
memory footprint we're going to hit per child process. Where will the
following caches live?
* necko memory cache (parent process)
* imglib cache (compressed image data... parent process?)
* imglib decompressed buffers (child process, or memory-mapped from the parent?)
* font caches (font metrics data can get pretty large, and is rather
expensive to construct IIRC... but it also doesn't sound easy to memory-map
or share across processes)
* history (mainly needed for link coloring)... parent process
--BDS
John J. Barton
> Hello all,
>
> This is a summary of a set of discussions that started between a set of
> individuals in person at the Firefox summit, and briefly continued
> recently in a private email thread.
I suppose the option of waiting until the Chromium operating system has
been proven successful -- or not -- was considered and discarded? It's
their mistakes one wants to learn from.
jjb
Boris Zbarsky
> I suppose the option of waiting until the Chromium operating system has
> been proven successful -- or not -- was considered and discarded?
Actually, the conversation predated Google Chrome's announcement.
It was triggered by IE8beta, at least in part, and doing multiple
processes allows us to get security and stability benefits that are very
desirable.... As computers end up with more and more cores, this also
gets us a way to take advantage of those cores that might not be much
harder than trying to performantly multi-thread Gecko.
> It's their mistakes one wants to learn from.
True, but this is the sort of thing that will take a while to retrofit
on our codebase, so it's certainly not too early to at least do some
planning.
-Boris
hk9...@gmail.com
> Note that this is more complicated because e.g. we allow CSS loading. It's
> not clear to me that Chromium actually prevent cross-origin network loads at
> the process layer at all.
That is correct. Chromium's sandbox is designed to protect the user's
file system from the web, not to protect web sites from each other.
For more details about the security architecture, see:
http://crypto.stanford.edu/websec/chromium/
We're interested in making use of the sandbox to protect web sites
from each other, but that has a lot of additional complexities.
Collin and I would be happy to come by and discuss this stuff in
person if that would be more efficient than usenet.
> It sounds a lot easier, as a prototype, to actually have the child process
> as a native window with its own event loop; this has some definite
> drawbacks, but it would be a good start to get it working in this manner.
There is a big downside, from a security point of view, to giving the
untrusted process a native window handle. Granting access to an HWND
in Windows let's the untrusted process interact with the user's
desktop. For example, it can draw over arbitrary regions of the
screen and send messages to all the HWNDs on the current desktop. The
design of rendering to a bitmap and copying the bitmap to the screen
avoids these security pitfalls.
Adam
Jonas Sicking
> Johnny Stenback wrote:
>
>> same-origin checked etc. (Well, we don't currently know how that
>> currently works in Chrome either, since foreign-origin IFRAMEs are
>> hosted in the same renderer process as the container, but whatever.)
>> Having necko only in the master process would be largely benefitial to
>> us as the startup time and memory footprint cost of NSS is fairly
>> substantial, and having to take that hit per child process would be less
>> than ideal.
>
> Note that this is more complicated because e.g. we allow CSS loading. It's
> not clear to me that Chromium actually prevent cross-origin network loads at
> the process layer at all.
For things like CSS and images we could allow cross-site loads, but
never add things like cookies or authentication tokens. This means that
you generally can't load anything that isn't public data anyway.
This fails in two cases:
1. For users inside a firewall this still allows loading of
company-private data inside the firewall.
2. If we did this for script loads we would likely break a lot of sites
that use <script src="..."> to load JSON data cross site.
(This would also break things like iframes pointing cross origin,
however it's possible that frames could run in a separate processes.)
However it's possible that both these could be solved:
For 1 we could add the ability to configure what is an intranet site and
disallow loading internet->intranet (this is something that we should do
anyway). This wouldn't be required, but if you don't do it you'd risk
company private data being stolen if an employee runs a browser that
gets exploited.
For 2 we could require that Access-Control was used in order to get
cookies. This feature already exists in the Access-Control spec.
/ Jonas
Adam
> For things like CSS and images we could allow cross-site loads, but
> never add things like cookies or authentication tokens. This means that
> you generally can't load anything that isn't public data anyway.
Another option is to restrict cross-site loads to only the correct
Content-Types (e.g., text/css, image/*, application/javascript, etc).
Adam
brahmana
> Another thing that's been discussed/thought about, is the huge issue of
> what the extension model should look like. The big issue is of course
> what to do when an extension in the chrome process wants to touch
> content. After initial pessimism about this issue it seems we could
> actually preserve most of our current extension model. Here's what we're
> thinking:
When you say chrome process, will all chrome code run in a separate
global process or the main parent process or will each tab have two
processes - 1 for chrome i.e extensions and another for the content?
--Regards,
Brahmana.
Enrico Weigelt
Hi,
> Early on in the discussions it was suggested that the first step should
> be to enable profile sharing so that multiple processes can share a
> Necko cache, cookies, prefs, etc. But that's actually obviously wrong,
NAK (IMHO). If multiple processes can easily access profile data
simultaniously without disturbing each other other, we're a HUGE
step further - at least it would be quite trivial to have multiple
windows in separate (really separate!) processes.
How to do it ? Well, just let the filesystem handle it. But when
I say "filesystem", it doesn't necessarily mean the OS'es filesystem,
but more an tiny vfs library (eg. libmvfs) which also speaks nice
IPC/FS protocols like 9P/Styx. The various profile data objects are
presented as a filesystem hierachy - the clients (eg. browser windows,
settings stuff, etc, even up to completely external apps) now don't
care (more precisely: don't even know) where the actual data comes from,
it's up to a little fileserver to handle this.
For example bookmarks:
The whole bookmark tree is presented as a directory tree, where nodes
themselves are presented as directories and the properties as files.
Now you can easily walk through the tree and access the bm's you like,
changing properties by simply overwriting the appropriate file, creating
new ones just by mkdir, removing them just by rm.
That's even simple enough to be coded in VHDL and burned on an FPGA ;-P
Getting in other datasources like collaborative bookmarking services, etc,
is just a matter of mounting a proper filesystem.
Same for all other profile data objects.
> and it would also be a tediously hard process; the Chrome docs says that
> we shouldn't allow maliciously compromised processes from directly
> accessing the network to violate same-origin restrictions.
Something like webfs ?
Simply put the cache, filtering, proxy handling, etc into a webfs speaking
server and let everything that wants to access web resources speak to
the webfs filesystem. Then you're done, once and for all.
All the things that have to cope with networking - from content filtering
to offline browsing now are the job of a proper webfs server and quite
irrelevant to the actual browser.
(For the offline browsing: I'm planning to give wwwoffle an webfs interface,
we'll have that stuff solved for everyone, not just moz alone)
> Another thought along these lines was to use shared memory segments to
> share the data between processes, and use pipes primarily for smaller
> control data, and that would probably be a good IPC optimization to
> leverage here.
You're aware of the additional complexity and alll the headache it
triggers (beginning with the need for an crossplatform shm mechanism) ?
Do you *really* it's worth this ?
> One thing that obviously needs to be shared by the different processes
> is preferences. It would probably make the most sense to have the child
> processes ask the parent process for preference values. And this is
> actually very simple to implement w/o modifying the pref service API.
With 9P that's almost trivial: present the settings as a fs tree,
each property in a single file. Just mount the appropriate tree into
the client and all it takes is open()+read()+close(). Done, with less
than 10 LOC for e neat frontend func.
> There are a bunch of other design issues, like how to handle the
> rendering of subprocesses, how to handle plugins, and so on. Some of
Plugins - good point.
They should really run in the *completely* own process. Again,
communication via 9P: if the plugin's allowed to access the web,
it gets an webfs, if it's allowed to have it's subwindow, it gets
an rio window (/dev/draw+/dev/mouse+/dev/cons), if it's allowed
to access the network, it gets /net fs, etc, etc.
Now more hassle with broken-designed plugins (like flash) that
kills the whole browser and compromises system security.
Ah, before you're attempting to say, writing fileservers is
complicated: no it isn't, in fact w/ 9P it's fairly trivial.
Just have a look at libmixpsrv.
cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service - http://www.metux.de/
---------------------------------------------------------------------
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
---------------------------------------------------------------------
Boris Zbarsky
> NAK (IMHO). If multiple processes can easily access profile data
> simultaniously without disturbing each other other, we're a HUGE
> step further - at least it would be quite trivial to have multiple
> windows in separate (really separate!) processes.
Yes, but if they can all write to the profile, then you lose in terms of
security. So in security terms, we don't want to do this anyway.
>> Another thought along these lines was to use shared memory segments to
>> share the data between processes, and use pipes primarily for smaller
>> control data, and that would probably be a good IPC optimization to
>> leverage here.
>
> You're aware of the additional complexity and alll the headache it
> triggers (beginning with the need for an crossplatform shm mechanism) ?
> Do you *really* it's worth this ?
Is it more complexity than dealing with blocking behavior in pipes?
> With 9P that's almost trivial: present the settings as a fs tree,
> each property in a single file. Just mount the appropriate tree into
> the client and all it takes is open()+read()+close(). Done, with less
> than 10 LOC for e neat frontend func.
You know, at this point it's starting to sound like you have a solution
in search of a problem... Maybe 9P is indeed the answer to all
information sharing. But I somehow doubt it. What's the performance
overhead here? Some of the profile access is on the hot path in layout.
> Plugins - good point.
>
> They should really run in the *completely* own process. Again,
> communication via 9P
High-resolution video over 9P? That doesn't solve the problem of how to
get the data over efficiently; it just suggests an API for the data
access. The real problem is the implementation.
The same issue with most of your other suggestions, actually.
-Boris
Enrico Weigelt
> The design of rendering to a bitmap and copying the bitmap to
> the screen avoids these security pitfalls.
At this point we're just one step away from using /dev/draw / rio
for that job. And as a nice side effect we've got an platform
agnostic and network transparent solution.
Enrico Weigelt
> >NAK (IMHO). If multiple processes can easily access profile data
> >simultaniously without disturbing each other other, we're a HUGE
> >step further - at least it would be quite trivial to have multiple
> >windows in separate (really separate!) processes.
>
> Yes, but if they can all write to the profile, then you lose in terms of
> security. So in security terms, we don't want to do this anyway.
Access control in the profile server ?
> >You're aware of the additional complexity and alll the headache it
> >triggers (beginning with the need for an crossplatform shm mechanism) ?
> >Do you *really* it's worth this ?
>
> Is it more complexity than dealing with blocking behavior in pipes?
O_NDELAY ? select()-loop ? multithreading ?
> >With 9P that's almost trivial: present the settings as a fs tree,
> >each property in a single file. Just mount the appropriate tree into
> >the client and all it takes is open()+read()+close(). Done, with less
> >than 10 LOC for e neat frontend func.
>
> You know, at this point it's starting to sound like you have a solution
> in search of a problem...
Catched me - I'm playing the Skulls+Bones game ;-)
> Maybe 9P is indeed the answer to all information sharing. But I somehow
> doubt it. What's the performance overhead here?
Don't have any hard numbers (besides Plan9 benchmarks ;-)), but IMHO most
of Moz's bad performance comes from its complexity (the code paths tend
to be quite scary ;-P) - my suggested 9P approach makes it *very* simple.
Note that, in the end, we have several quite simple processes, so using hw
parallelism is inherent.
> Some of the profile access is on the hot path in layout.
Does it all have to be re-read everytime ?
Implementing a tiny read-cache in libmvfs is trivial (already done it
for metadata).
> >Plugins - good point.
> >
> >They should really run in the *completely* own process. Again,
> >communication via 9P
>
> High-resolution video over 9P?
What exactly do you mean with "high-resolution" ?
If I look at YT, that's not what I'd call so ;-o
BTW: we've already been at the point that the sub-processes should not
have direct access to the window, but paint to a vfb, which is then
sent to the master process(es). If we're already here, we can directly
use /dev/draw or maybe an more improved highlevel interface for this.
> That doesn't solve the problem of how to
> get the data over efficiently; it just suggests an API for the data
> access. The real problem is the implementation.
The worst problem for implementation is complexity, and my suggested
interface(s) cuts down complexity radically and eases development.
For a better understanding you might like to have a deeper look
into Plan9+friends. Maybe you first have to see it with your own
eyes, feel it by yourself, to really understand the big plot.
I admit, I also had my difficulties, but someday there was some
moment of "enlightenment" which radically changed my way of thinking
about SE ;-)
It's not about trying to cut a few cycles here and there, instead it's
about dramatically get rid of old pollution legacy which grows up
complexity day by day ;P
Boris Zbarsky
> Access control in the profile server ?
That's no different from serializing the profile access through the UI
process in some way. I believe the suggestion that jst said wouldn't
work, and that you said should in your original mail, is full concurrent
access from all of the worker processes to the profile.
>> Is it more complexity than dealing with blocking behavior in pipes?
>
> O_NDELAY ? select()-loop ? multithreading ?
multithreading is a particular hell we'd like to avoid, yes.
>> Some of the profile access is on the hot path in layout.
>
> Does it all have to be re-read everytime ?
> Implementing a tiny read-cache in libmvfs is trivial (already done it
> for metadata).
Tiny read cache doesn't help for the specific hot-path case of visited
link coloring. You need to be able to do very fast lookups to determine
whether a given URI has ever been visited.
> What exactly do you mean with "high-resolution" ?
> If I look at YT, that's not what I'd call so ;-o
YouTube is aimed at the current lowest common denominator. I'm talking
streaming HD here. If we're talking about designing for a few years
from now, that's the target we need to hit.
> The worst problem for implementation is complexity
Agreed.
> and my suggested interface(s) cuts down complexity radically and eases development.
This I don't think I buy.
> It's not about trying to cut a few cycles here and there, instead it's
> about dramatically get rid of old pollution legacy which grows up
> complexity day by day ;P
Note that a lot of the complexity in Gecko has to do with trying to deal
with reverse engineering and moving targets. I'm not expecting this
sort of complexity to arise here, no matter what API we choose.
-Boris
Enrico Weigelt
Hi,
> >Access control in the profile server ?
>
> That's no different from serializing the profile access through the UI
> process in some way.
Oh, there is an BIG difference: that separate profile server can
be easily replaced, eg. for things like roaming, collaborative
bookmarks, etc, etc.
Ah, and it can be easily used by other clients (outside the Moz world)
> I believe the suggestion that jst said wouldn't work, and that you said
> should in your original mail, is full concurrent access from all of the
> worker processes to the profile.
Why exactly should it not work ?
> >>Is it more complexity than dealing with blocking behavior in pipes?
> >
> >O_NDELAY ? select()-loop ? multithreading ?
>
> multithreading is a particular hell we'd like to avoid, yes.
Aha, and the attempt to scheduling naturally parallel tasks all by
yourself is heaven ? Why does Moz then block every fews secs as soon
it comes under some load ?
> Tiny read cache doesn't help for the specific hot-path case of visited
> link coloring. You need to be able to do very fast lookups to determine
> whether a given URI has ever been visited.
Simple solution:
* on process startup, a hash list of the history URLs is loaded
(or maybe inherited from the forking parent process)
* visited URLs are sent to the profile server through an command channel
* the profile server sends back new visited URLs's hashes to the clients
Okay, we'll then have one hashtable (w/o content, just keys) per
child process (does it hurt so bad ?), but this frees us from locking
issues, etc.
> >What exactly do you mean with "high-resolution" ?
> >If I look at YT, that's not what I'd call so ;-o
>
> YouTube is aimed at the current lowest common denominator. I'm talking
> streaming HD here. If we're talking about designing for a few years
> from now, that's the target we need to hit.
Add video support to the display server ?
> Note that a lot of the complexity in Gecko has to do with trying to deal
> with reverse engineering and moving targets. I'm not expecting this
> sort of complexity to arise here, no matter what API we choose.
Mozilla is more than just Gecko, isn't it ? ;-o
Boris Zbarsky
>> I believe the suggestion that jst said wouldn't work, and that you said
>> should in your original mail, is full concurrent access from all of the
>> worker processes to the profile.
>
> Why exactly should it not work ?
Because we don't want to allow full access. We want to allow carefully
vetted restricted access based on what we know about those processes
(NOT what they claim about themselves).
> Aha, and the attempt to scheduling naturally parallel tasks all by
> yourself is heaven ? Why does Moz then block every fews secs as soon
> it comes under some load ?
Because there is a lot of run-to-completion code around (ranging from
layout to the GC and cycle collector). The right solution there is
making things interruptible or reducing the scope of the work set they
deal with.
And no, manual scheduling is not heaven, but there are non-thread
solutions to the concurrency problem that aren't quite as nasty as
threads are. There aren't any non-nasty solutions that I know of.
> * on process startup, a hash list of the history URLs is loaded
> (or maybe inherited from the forking parent process)
This might be airly significant memory overhead. 50 days worth of
history (which I believe is the default) includes a lot of URLs. You're
suggesting eating that memory overhead per tab. Worse yet, this way the
child process has the list of all the visited URLs, so if it's
compromised the attacker gets them all. We _do_ want to fix this
:visited query thing sometime, and at that point we'd want pretty
limited information about the history available to the child processes.
>> Note that a lot of the complexity in Gecko has to do with trying to deal
>> with reverse engineering and moving targets. I'm not expecting this
>> sort of complexity to arise here, no matter what API we choose.
>
> Mozilla is more than just Gecko, isn't it ? ;-o
While true, a lot of the complexity is in fact Gecko. I'm not sure that
after looking at tabbrowser.xml I'd say "most", but a lot.
-Boris
Robert Kaiser
> This might be airly significant memory overhead. 50 days worth of
> history (which I believe is the default) includes a lot of URLs.
Actually, since introduction of places and it's good search performance,
we now keep 180 days or 40,000 history URLs (whichever gets hits first)
by default - which means even more overhead with his solution, of
course. ;-)
Robert Kaiser
Enrico Weigelt
> Because we don't want to allow full access. We want to allow carefully
> vetted restricted access based on what we know about those processes
> (NOT what they claim about themselves).
I don't see the big problem here. Permission handling is something
the fileserver should handle. Shouldn't be such a deal to code an
generic ACL handling for libmixpsrv (sitting in the middle between
9P core and the actual server ops).
Feel free to post your requirements here, and I'll sit down and
code it as soon as I got some spare time ;-p
> >Aha, and the attempt to scheduling naturally parallel tasks all by
> >yourself is heaven ? Why does Moz then block every fews secs as soon
> >it comes under some load ?
>
> Because there is a lot of run-to-completion code around (ranging from
> layout to the GC and cycle collector). The right solution there is
> making things interruptible or reducing the scope of the work set they
> deal with.
Making complex ops interruptible is far from being a trivial job.
Imagine something that depends on things you can't even see (eg. deep
in the widget toolkit, involving network connections, etc) - you'll
need interruptible/restartable infrastructure down the whole codepath
to that point where the blocking actually comes from.
I really doubt that this is really easier and more stable than just
letting the kernel do all the dirty work ;-P
> >* on process startup, a hash list of the history URLs is loaded
> > (or maybe inherited from the forking parent process)
>
> This might be airly significant memory overhead. 50 days worth of
> history (which I believe is the default) includes a lot of URLs.
No, we don't need the whole history here. All we need to know for
link coloring is whether some URL *is* in history, nothing more.
We even don't need the actual URLs - a hashtable (only of hashes,
w/o any associated data) would be perfectly fine.
Once a viewer hits some URL, it just tells the history server
(and just the plain URL). Only if this URL is *new* to the history,
the history server sends back the hash to it's clients.
> Worse yet, this way the child process has the list of all the
> visited URLs, so if it's compromised the attacker gets them all.
As said above, it won't. It just has a list of hashes.
Boris Zbarsky
> Feel free to post your requirements here, and I'll sit down and
> code it as soon as I got some spare time ;-p
The fundamental requirement is that we need to have a set of processes
(possibly bounded above), and for each process we need to have a set of
resources it's allowed to access. The set of resources may be changed
based on information we have about the process, but it must not change
based on information the process provides. Fundamentally, assume that
all the processes are compromised.
It's pretty vague so far, because we're not yet sure what resources need
to be locked down this way.
> Making complex ops interruptible is far from being a trivial job.
> Imagine something that depends on things you can't even see (eg. deep
> in the widget toolkit, involving network connections, etc) - you'll
> need interruptible/restartable infrastructure down the whole codepath
> to that point where the blocking actually comes from.
Yes, I'm well aware.
> I really doubt that this is really easier and more stable than just
> letting the kernel do all the dirty work ;-P
The problem is that there is no way to let the kernel do the dirty work.
If your tab locks up it locks up. The UI can stay responsive and
that's great, but that doesn't help the user who's trying to interact
with the tab. So if you have non-interruptible operations your painting
depends on, you just lose.
-Boris
Enrico Weigelt
Hi,
> The fundamental requirement is that we need to have a set of processes
> (possibly bounded above), and for each process we need to have a set of
> resources it's allowed to access.
More precise please ;-P
I, personally, would start with things plugins. What they need:
* video playback (raster+vector)
* audio playback
* video recording
* audio recording
* input events
* config storage (eg. for passing parameters from browser to plugin)
* command channel plugin->browser
* command channel browser->plugin
* web access
* network access
All these things should be in a blockable, and can be easily implemented
via a filesystem protocol like 9P.
> >I really doubt that this is really easier and more stable than just
> >letting the kernel do all the dirty work ;-P
>
> The problem is that there is no way to let the kernel do the dirty work.
> If your tab locks up it locks up. The UI can stay responsive and
> that's great, but that doesn't help the user who's trying to interact
> with the tab.
At least only that tab locks up and could be killed separately. Better
than having the whole browser crashing (which, at my site, happens
very often). If at least plugins were moved out, they couldn't do much
harm anymore - in worst case, just kill the process and done.
> So if you have non-interruptible operations your painting
> depends on, you just lose.
Threads ?