= $all-$resolved ?> Open; = $resolved ?> Resolved; = $all ?> Total (66.67% complete)
Introduce the Feature
Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)
FOTA: Full over-the-air updates (i.e. Gonk/Drivers/Firmware + Gecko + Gaia)
Purpose: Only for security bugs that can't be fixed in Gecko or Gaia. Ideally are never needed for shipping devices.
Frequency: Immediate for critical security bugs. Quarterly for any non-critical security bugs, if needed. If there are no bug fixes in a given quarter, there is no quarterly update.
Integrity checking: Update packages will be signed .mar files (inside the mar file will be a zip file containing the update)
Update server(s): Currently AUS, production undecided.
Delivery: Updates will be provided over a private APN? (what about Wifi?)
- Device checks for new update manifest (e.g. http://update.boot2gecko.org/nightly/update.xml)
- Download update via existing firefox delivery mechanism (updater & mar)
- If there is an update, it is downloaded over http, probably via cdn.
- Downloaded .mar file is checked against the hash in the manifest
- Updater runs to check signatures and update details
- Sets up recovery partition (copy files and create recovery commands)
- Reboot in to recovery mode
- Recovery checks a signature of the oem key
- return back to normal mode after installation
- status checking afterwards
Backup keys possible in mar file, but not in android
Purpose: Automatic updates of b2g "userspace" (gecko, built-in apps and dependencies; not third-party apps)
- 42 weeks (ESR) > update cycle > 6 weeks (Firefox)
- Current proposal is 18 weeks
Integrity checking: MAR Signing as above & Gaia apps also signed as per packaged apps.
Update server(s): Not decided yet.
Delivery: Updates will be provided over a private APN. (Wifi? Download to PC then USB update?)
Update flow: https://wiki.mozilla.org/images/4/46/SystemUpdates_Flow1.pdf
Downloading checking signature of updates as per the process above.
- system partition is read-only
- updater mounts the partition as read-write, copies files across
- remounts partition as read-only
- b2g process is restarted
- in case of error the device is rebooted (not normally required though)
What solutions/approaches were considered other than the proposed solution?
- Why three signatures?
- support for contractual relationships
- Who has final say in the case of disagreement on timing or content of updates?
- open question, to discuss with carriers
Why was this solution chosen?
Any security threats already considered in the design and why?
Update is modified in transit or prior to being applied
- SSL used for the update manifest (including hash of update content)
- Updates signed (potentially by all 3 keys)
Updates not available in timely fashion
- How urgent update process will work is an open question, currently being negotiated with partners.
- Open question on how frequency will work with multiple carriers. Possibly have Gecko/Gaia updates Mozilla signed only.
Open questions: Who will host updates? Will users be able to get updates over WiFi or USB?
|Action Item Status||In Progress|
|bbondy::Check to make the update is not significantly larger than expected to prevent disk space being exhausted::https://bugzilla.mozilla.org/show_bug.cgi?id=801855 Resolved
pauljt:: Fuzz mar format::804046 Resolved