On 04/19/2012 10:46 AM, Jarred Nicholls wrote: > On Thu, Apr 19, 2012 at 12:59 PM, Jim Straus <jstr...@mozilla.com> wrote: >>> ====Content Processes==== >>> * All Web Apps run in a low-rights content process (B2G content process) >> spawned via fork() by the b2g process (B2G Core process). These content >> processes are sandboxed to have no direct access to file system or OS. B2G >> content processes can only communicate through IPC mechanism (IPDL) back to >> the B2G core process, which will perform actions on behalf of content. >> >> We'll need to be careful of what is currently known to the Core process >> when the fork is done to keep the content processes from having access to >> various parts of the core process. Might it be better to exec the content >> processes? >> > > Same thing came to mind. On posix Chromium fork()'s and obtains the child > pid, then in the child builds up a (crazy long) list of args to pass state > & other info, e.g. IPC channel ids, and then does an execvp() for the > renderer process. > >
That sounds good to me as well. >>> ==== OS Update ==== >>> >>> OS updates includes everything except gecko, which has its own update >> process (see below). >>> OS updates are issued when a user-impacting bug or a security bug is >> found, or when a required for a B2G major upgrade. >>> >>> OS Updates can be done in 2 different ways. >>> >>> 1) Via a firmware image, through USB. The fast boot booloader is >> required. Note that this can be used to install any other OS as well and >> has no restrictions. >>> This method is also used when method 2) fails (power issue, hardware >> failure, etc.) and "brick" the device. >> >> Can the fastbootloader require signatures even for USB updates? It seems it can when it's hardcoded (glue/gonk/bootable/bootloader/legacy/usbloader/usbloader.c #if REQUIRE_SIGNATURE) although the use case would generally be "vendor wants to lock the boot loader". Unlocking the boot loader to flash otherwise deletes user content for privacy (ie device stolen). That being said, encryption would be largely favored over this. _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
