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? 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
