<html><body><p><tt><font size="2">> LPC itself doesn't have any ECC on it, so we *could* get bit flips<br>> transferring from the BMC, but these would be caught by secure boot or<br>And we have seen these. I know of situations where the ECC correction allowed us to boot when otherwise we couldn't. There are also partitions that aren't signed (our writable stuff). With that said, this does seem like something to be looked at going forward.</font></tt><br><br><tt><font size="2">> At some point early in Hostboot, it protects the SBE SEEPROM from being<br>> written. It does this so that you can't then compromise secure boot, and<br>The processor hardware itself boots to a state where you can't write the SBE from anyone but the host, that is based on the secure jumper. Later on we close down host access as well.</font></tt><br><font size="2"><br>--<br>Dan Crowell<br>Senior Software Engineer - Power Systems Enablement Firmware<br>IBM Rochester: t/l 553-2987<br>dcrowell@us.ibm.com</font><br><br><img width="16" height="16" src="cid:1__=09BB0ED0DFDCAB408f9e8a93df938690918c09B@" border="0" alt="Inactive hide details for Stewart Smith ---07/26/2019 01:15:53 AM---"Marty E. Plummer" <hanetzer@startmail.com> writes: > On Mo"><font size="2" color="#424282">Stewart Smith ---07/26/2019 01:15:53 AM---"Marty E. Plummer" <hanetzer@startmail.com> writes: > On Mon, Jul 22, 2019 at 04:14:50PM +1000, Stew</font><br><br><font size="2" color="#5F5F5F">From: </font><font size="2">Stewart Smith <stewart@linux.ibm.com></font><br><font size="2" color="#5F5F5F">To: </font><font size="2">"Marty E. Plummer" <hanetzer@startmail.com>, openpower-firmware@lists.ozlabs.org</font><br><font size="2" color="#5F5F5F">Date: </font><font size="2">07/26/2019 01:15 AM</font><br><font size="2" color="#5F5F5F">Subject: </font><font size="2">[EXTERNAL] Re: [OpenPower-Firmware] SBE questions</font><br><font size="2" color="#5F5F5F">Sent by: </font><font size="2">"OpenPower-Firmware" <openpower-firmware-bounces+dcrowell=us.ibm.com@lists.ozlabs.org></font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br><br><tt><font size="2">"Marty E. Plummer" <hanetzer@startmail.com> writes:<br><br>> On Mon, Jul 22, 2019 at 04:14:50PM +1000, Stewart Smith wrote:<br>>> "Marty E. Plummer" <hanetzer@startmail.com> writes:<br>>> >> I might suggest going in reverse order though through the firmware<br>>> >> stack, first get skiboot to understand CBFS (likely in a simulator like<br>>> >> qemu or Mambo - aka POWER9 Functional Simulator), then get Hostboot to<br>>> >> understand it, then the Hostboot Boot Loader.<br>>> >> <br>>> >> TBH, re-using a data structure and code for it for our flash layout<br>>> >> would be an improvement over what we have now.<br>>> > I cannot parse this statement, could you rephrase?<br>>> <br>>> The FFS format that we use is something that is ill-defined and<br>>> strangely custom. It also has *multiple* implementations to parse and<br>>> generate it.<br>>> <br>> Ah, gotcha. So there's a lot of code duplication up and down the stack.<br>> Yeah, having a common implementation would be nice.<br><br>We have libflash/ from the skiboot tree, which is used in a few places<br>at least, and that's probably the leading candidate.<br><br>>> >> Looking at the Coreboot docs, it looks like there's a redesign of cbfs<br>>> >> going on? Perhaps even replacing it with Flashmap?<br>>> >> <br>>> > Beware the docs. Their are two sets, one is old wiki and the other is<br>>> > generated from the coreboot repo's documentation tree.<br>>> <br>>> I saw nothing about CBFS in the documentation tree, just on the wiki.<br>>> <br>> Yeah... Also I'm gonna have fun implementing ecc support (assuming there<br>> is none already) as it would suck to lose features while moving<br>> platforms.<br><br>So, there's only real one use for ECC anymore.<br><br>Back on POWER8 systems we originally talked directly to the flash<br>controller to read the flash. If there were ECC errors there, we could<br>correct them. Notably, not *all* of firmware needed to boot was ECC'd,<br>so there was only about half of the firmware needed to boot that you<br>could possibly have an ECC error in and still boot. So, effectively<br>pretty damn useless.<br><br>Now with mbox and hiomap, we're just reading the data over LPC from RAM<br>on the BMC. The BMC presumably has a sensible way to ensure there's not<br>errors on storage (e.g. data checksums), and we also have Secure Boot<br>enforcing that the hashes match (and xz compression with CRC32<br>checksums). So any bit error *will* be detected, although not<br>*corrected*.<br><br>LPC itself doesn't have any ECC on it, so we *could* get bit flips<br>transferring from the BMC, but these would be caught by secure boot or<br>the CRC32 in xz compression, so a simple reboot would probably fix<br>things.<br><br>I'm not sure there's any value in continuing to have ECC anywhere TBH.<br><br>>> >> There have been *two* PoC implementations of UEFI for POWER, and it's<br>>> >> something we've discussed a few times. The biggest disadvantage is that<br>>> >> it's a giant monstor of a code-stack that has to be maintained, and<br>>> >> there just aren't resources for it. Balance that with the "you can take<br>>> >> Petitboot from our cold dead hands" attitude of anyone who ever uses it<br>>> >> after any other firmware environment, and I'm not sure we'd gain much<br>>> >> there.<br>>> >> <br>>> > Yeah, petitboot is hella nice. I stuck it into the 8mb flash on my kevin<br>>> > chromebook (lotta compression needed there!)<br>>> <br>>> Wow, we barely fit things into 16MB.<br>>><br>> It was a rather fun process. Eventually I'll put together a forked<br>> op-build which creates the image for use in coreboot automatically<br>> (currently I manually compress the kernel Image and make the fit<br>> image)<br><br>I think Jeremy has a plan to upstream the petitboot makefile to<br>buildroot, and then you should be able to create that image purely with<br>upstream buildroot rather than needing op-build.<br><br>>> >> Probably the most terrifying thing about hacking on OpenPOWER firmware<br>>> >> is bricking your SBE.<br>>> >> <br>>> > Actually, my investigations says that (at least on talos) its relatively<br>>> > easy to reprog the sbe... I've done a full wipe and rewrite from a dump<br>>> > earlier, just some file called eeprom under /sys/devices/platform/ahb/...<br>>> > cat to dump, cat from /dev/zero to nuke, cat from eeprom dump to eeprom<br>>> > sysfs file, back exactly how it was before.<br>>> <br>>> Sweet! I was kind of hoping that would magically work on OpenBMC platforms.<br>>> <br>> Yeah. Although not all the seeproms are broke out like this (honestly<br>> I'm a bit confused on the counts here as I've seen references to three,<br>> two, and one seeprom on the cpu so I really don't know how many there<br>> are). Apparently only one is presented on the bmc i2c bus so if I write<br>> a new sbe firmware and write it to that seeprom I'm not certain that's<br>> the one that will 'take' and boot the new coreboot path... do you happen<br>> to know of any way to access the other seeprom(s) to write the new<br>> firmware from the power9 userspace? Its my understanding that that bus<br>> is protected somehow from the view of the power9 after we get to<br>> userspace.<br><br>At some point early in Hostboot, it protects the SBE SEEPROM from being<br>written. It does this so that you can't then compromise secure boot, and<br>it's also a nice bit of brick protection.<br><br>-- <br>Stewart Smith<br>OPAL Architect, IBM.<br>_______________________________________________<br>OpenPower-Firmware mailing list<br>OpenPower-Firmware@lists.ozlabs.org<br><a href="https://lists.ozlabs.org/listinfo/openpower-firmware">https://lists.ozlabs.org/listinfo/openpower-firmware</a> <br><br></font></tt><br><br><BR>
</body></html>