Hi, I have some concerns toward the current B2G model at the OS/kernel level, which I have discussed with various people already. I'd like to raise awareness about these concerns and see if we currently have a solution, or if a solution is really planned.
Note that the solution is likely to be electrolysis, but, while it's on the roadmap, as far as I understand, it is likely that B2G won't actually ship with electrolysis enabled, nor would it really be planned in the future. (I also understand that having a proper "1 process per window" electrolysis with the current code base may be a huge task). The main concern is that B2G currently uses a single process model, where the userspace API handles and control hardware (think WebAPI) and memory access (and perhaps more) for the apps. More specifically, the apps run in the same process as the API itself. This raises both reliability and security concerns IMO. This means the OS/kernel has no control over it. Here is the list of issues I see with that model: - Memory bound checking is done via the JS engine, any bug there, and everything (apps Gecko) may be compromised, or crashes. * Kernel level (or even CPU level) memory using paging in protected mode (default) ensure an app (aka a process) can only break itself - Resource usage is not controlled, AFAIK * Kernel level resource control can freeze or regulate apps (control groups and limits in Linux) - Can't use regular Linux access control, since everything happens in one process * When using separate processes, all I/O, IPC, etc uses system calls and can be controlled via various models such as SELinux, etc. There may be additional issues and the list could, I suppose, be extended. While using electrolysis is arguable for a "regular" browser, I think it's something important to think about for a browser which supports WebAPI, and which is designed to run most of the apps on the system. Guillaume _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
