[OpenPower-Firmware] SBE questions

Sat Jul 27 00:28:47 AEST 2019

> LPC itself doesn't have any ECC on it, so we *could* get bit flips
> transferring from the BMC, but these would be caught by secure boot or
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.

> At some point early in Hostboot, it protects the SBE SEEPROM from being
> written. It does this so that you can't then compromise secure boot, and
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.

--
Dan Crowell
Senior Software Engineer - Power Systems Enablement Firmware
IBM Rochester: t/l 553-2987
dcrowell at us.ibm.com

From:	Stewart Smith <stewart at linux.ibm.com>
To:	"Marty E. Plummer" <hanetzer at startmail.com>,
            openpower-firmware at lists.ozlabs.org
Date:	07/26/2019 01:15 AM
Subject:	[EXTERNAL] Re: [OpenPower-Firmware] SBE questions
Sent by:	"OpenPower-Firmware" <openpower-firmware-bounces
            +dcrowell=us.ibm.com at lists.ozlabs.org>

"Marty E. Plummer" <hanetzer at startmail.com> writes:

> On Mon, Jul 22, 2019 at 04:14:50PM +1000, Stewart Smith wrote:
>> "Marty E. Plummer" <hanetzer at startmail.com> writes:
>> >> I might suggest going in reverse order though through the firmware
>> >> stack, first get skiboot to understand CBFS (likely in a simulator
like
>> >> qemu or Mambo - aka POWER9 Functional Simulator), then get Hostboot
to
>> >> understand it, then the Hostboot Boot Loader.
>> >>
>> >> TBH, re-using a data structure and code for it for our flash layout
>> >> would be an improvement over what we have now.
>> > I cannot parse this statement, could you rephrase?
>>
>> The FFS format that we use is something that is ill-defined and
>> strangely custom. It also has *multiple* implementations to parse and
>> generate it.
>>
> Ah, gotcha. So there's a lot of code duplication up and down the stack.
> Yeah, having a common implementation would be nice.

We have libflash/ from the skiboot tree, which is used in a few places
at least, and that's probably the leading candidate.

>> >> Looking at the Coreboot docs, it looks like there's a redesign of
cbfs
>> >> going on? Perhaps even replacing it with Flashmap?
>> >>
>> > Beware the docs. Their are two sets, one is old wiki and the other is
>> > generated from the coreboot repo's documentation tree.
>>
>> I saw nothing about CBFS in the documentation tree, just on the wiki.
>>
> Yeah... Also I'm gonna have fun implementing ecc support (assuming there
> is none already) as it would suck to lose features while moving
> platforms.

So, there's only real one use for ECC anymore.

Back on POWER8 systems we originally talked directly to the flash
controller to read the flash. If there were ECC errors there, we could
correct them. Notably, not *all* of firmware needed to boot was ECC'd,
so there was only about half of the firmware needed to boot that you
could possibly have an ECC error in and still boot. So, effectively
pretty damn useless.

Now with mbox and hiomap, we're just reading the data over LPC from RAM
on the BMC. The BMC presumably has a sensible way to ensure there's not
errors on storage (e.g. data checksums), and we also have Secure Boot
enforcing that the hashes match (and xz compression with CRC32
checksums). So any bit error *will* be detected, although not
*corrected*.

LPC itself doesn't have any ECC on it, so we *could* get bit flips
transferring from the BMC, but these would be caught by secure boot or
the CRC32 in xz compression, so a simple reboot would probably fix
things.

I'm not sure there's any value in continuing to have ECC anywhere TBH.

>> >> There have been *two* PoC implementations of UEFI for POWER, and it's
>> >> something we've discussed a few times. The biggest disadvantage is
that
>> >> it's a giant monstor of a code-stack that has to be maintained, and
>> >> there just aren't resources for it. Balance that with the "you can
take
>> >> Petitboot from our cold dead hands" attitude of anyone who ever uses
it
>> >> after any other firmware environment, and I'm not sure we'd gain much
>> >> there.
>> >>
>> > Yeah, petitboot is hella nice. I stuck it into the 8mb flash on my
kevin
>> > chromebook (lotta compression needed there!)
>>
>> Wow, we barely fit things into 16MB.
>>
> It was a rather fun process. Eventually I'll put together a forked
> op-build which creates the image for use in coreboot automatically
> (currently I manually compress the kernel Image and make the fit
> image)

I think Jeremy has a plan to upstream the petitboot makefile to
buildroot, and then you should be able to create that image purely with
upstream buildroot rather than needing op-build.

>> >> Probably the most terrifying thing about hacking on OpenPOWER
firmware
>> >> is bricking your SBE.
>> >>
>> > Actually, my investigations says that (at least on talos) its
relatively
>> > easy to reprog the sbe... I've done a full wipe and rewrite from a
dump
>> > earlier, just some file called eeprom
under /sys/devices/platform/ahb/...
>> > cat to dump, cat from /dev/zero to nuke, cat from eeprom dump to
eeprom
>> > sysfs file, back exactly how it was before.
>>
>> Sweet! I was kind of hoping that would magically work on OpenBMC
platforms.
>>
> Yeah. Although not all the seeproms are broke out like this (honestly
> I'm a bit confused on the counts here as I've seen references to three,
> two, and one seeprom on the cpu so I really don't know how many there
> are). Apparently only one is presented on the bmc i2c bus so if I write
> a new sbe firmware and write it to that seeprom I'm not certain that's
> the one that will 'take' and boot the new coreboot path... do you happen
> to know of any way to access the other seeprom(s) to write the new
> firmware from the power9 userspace? Its my understanding that that bus
> is protected somehow from the view of the power9 after we get to
> userspace.

At some point early in Hostboot, it protects the SBE SEEPROM from being
written. It does this so that you can't then compromise secure boot, and
it's also a nice bit of brick protection.

--
Stewart Smith
OPAL Architect, IBM.
_______________________________________________
OpenPower-Firmware mailing list
OpenPower-Firmware at lists.ozlabs.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.ozlabs.org_listinfo_openpower-2Dfirmware&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=mCj3CQvqek9g0fdziO-GEHyU1m9T3SAh0ZPd5s_AGpo&m=qzQMUL4OxE9rn0xiz3u_jQW7q3RplQ6uA_mdnus-6eM&s=Y2S3EPYv_2S2qWxmMey2nM0k2Uw-aOb5_Tofsb1iZdA&e=

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openpower-firmware/attachments/20190726/4dd5d45b/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openpower-firmware/attachments/20190726/4dd5d45b/attachment.gif>