Hi, To add a few things to Olof's comments: On Fri, Jun 6, 2014 at 2:49 PM, Olof Johansson <olof@xxxxxxxxx> wrote: >> What we can do, though, is to publicly shame you all Google People very >> strongly for not making firmware updates in the field safer and easier. >> After all you must all know already that, by definition, software always >> contains bugs. The first feature to be tested with a new >> bootloader/firmware must be the ability to successfully and safely (and >> securely) update itself. Especially for a mainstream device like a >> Chromebook. > > The security model of Chrome OS is that it relies on a read-only firmware > that is later verifying and launching a read-write firwmare. Obviously > changes to the read-only firwmare is impossible in the field (and only > done at risk of bricking the device for hobbyists). Some changes are > not possible to work around in the read-write part of the firmware, > or for some other reason becomes unfeasible to handle there. > > We're working on making the RO portion smaller, so we'll be less exposed > to this in the future, but that's a feature that will take some time > to mature. One thing to be aware is that despite the fact that these machines just came out, their firmware has been roughly frozen (no major changes) since last September due to various (non-technical) issues. We almost got the massive rewrite in before the deadline (talk to Simon Glass about this) but didn't quite make the deadline. :( Note that handling CPU resume in a way that can be updated by RW firmware is non-trivial and requires some SRAM to be saved across suspend/resume. On the original Samsung Chromebook we didn't have that. On the Samsung Chromebook 2 we do (yay!) but we didn't realize it until pretty late in the game. Sigh. -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |