On Fri, Jul 23, 2021 at 12:13 PM James Feeney <ja...@nurealm.net> wrote: > > On 7/23/21 8:07 AM, Matt DeVillier wrote: > > Thanks for your review. > > >> Are there any other things to try, before heating-up the soldering iron? > >> Is there any way to cross-check what flashrom is seeing? Is there any way > >> for Cr50 to directly access the AP boot flash memory itself and then > >> report through the Cr50 console, without involving flashrom? > > I don't believe so, someone from Google would likely be able to better > > answer > > > > That seems like shortsightedness from Google, not providing some kind of > internal test/verification function for some hardware I/O. > > >> As to the "broken hardware" theory, have you ever heard of anyone > >> attaching a flash programmer to a Google octopus board and successfully > >> reading flash memory content *in circuit*? > > never tried since CCD option is available, but in theory it should be > > possible. > > > > Hmm - tentatively, it might be useful to other people to offer the advise > "NEVER attach an in-circut flash programmer to an octopus board!" I don't > know that anyone would want to actually test this conjecture with their own > hardware. It looks like I may have to buy the service manual from Samsung, > but they refuse to tell me whether it includes the schematics. > > Ironically, the inability to attach a flash programmer in-circuit to a > Chromebook having Google's H1 security chip represents a kind of security > failure. Specifically, how is the boot flash content to be verified with the > certainty that the true content has not been hidden by Cr50, or by, for > instance, flashrom running from eMMC root, when the AP is used to read the > boot flash?
Inability? due to it being a WSON-8 chip or? Every Chromebook since ~2013 has supported ISP, AFAIK. And up until recently, most used a clippable SOIC-8 chip. > > It cannot be verified. The only alternative is to unsolder the flash chip, > and read it externally. Of course, if Cr50 has been compromised, verifying > boot flash may not matter. But then, in the end, this is Google's "Security > by Obscurity - just hide it in hardware" strategy, since I don't know that > there is any way to verify the Cr50 code running in the H1 chip. You'd think > that, by now, people would have given-up on the "Security by Obscurity" > strategy - but I suppose that marketing and management have still not > caught-up, gotten the memo, whatever - "Intellectual Property Rights", "Trade > Secrets", "National Security", blah, blah, blah. > > Also ironically, the actual cost to provide circuit protection for in-circuit > flash programming is approximately "zero" - the cost of a few resistors and > maybe a diode. I found this interesting: > > "Integrity Enhancements for Embedded Linux Devices", David Safford > https://selinuxproject.org/~jmorris/lss2013_slides/safford_embedded_lss_slides.pdf > > It looks like the maximum current on a typical ARM SC300 GPIO, as used for > the H1, is about 4mA. Compare this to the maximum current available from a > typical buffer output, as from a flash programmer, of about 50mA, if these > circuits were to be directly connected. > > </rant> > > James _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
