[Skiboot] [PATCH] core/flash: fix part_actual size

Tue Oct 25 09:13:05 AEDT 2016

Here are the test cases I tested. The images were built using op-build
upstream, master-next branch.

With trusted mode ON. For this I had to apply two simple patches on
hostboot and habanero-xml, otherwise the /ibm,secureboot node is not
created. The patch worked in the four scenarios below (capp and
bootkernel were properly measured and executed)
- capp signed
- capp unsigned
- bootkernel signed
- bootkernel unsigned

With secure mode ON. For this I had to force secure mode ON in skiboot
code - libstb/stb.c:30. Skiboot should be able to verify CAPP in the
scenario below, but it wasn't because the hw-key-hash got clobbered in
my SEEPROM by one of the SEEPROM updates performed by hostboot. All I
can see in /ibm,secureboot/hw-key-hash is a bunch of zeros. However, I
hard coded the expected hw-key-hash in skiboot code
(libstb/drivers/romcode.c) to test the scenario below, and the patch
worked for me, both capp and bootkernel were verified and measured. So
the problem in this scenario is not the patch, but the hw-key-hash that
got clobbered in my SEEPROM. Nick Bofferding is building a new
transition key driver to restore my SEEPROM.
- capp signed and bootkernel signed.

Here is the log for the scenario you mentioned, where CAPP and
BOOTKERNEL are not signed and trusted mode is ON.

root at p7pite01os:~# grep STB /sys/firmware/opal/msglog
[    3.077351366,5] STB: secure mode off (flag ignored)
[    3.077413251,5] STB: trusted mode on
[    3.285221905,5] STB: sb_verify skipped resource 2, secure_mode=0
[    3.285369745,6] STB: CAPP sha512 hash calculated
[    3.354563470,5] STB: CAPP measured to pcr2
[   13.258613578,5] STB: sb_verify skipped resource 0, secure_mode=0
[   13.313564911,6] STB: BOOTKERNEL sha512 hash calculated
[   13.372513439,5] STB: BOOTKERNEL measured to pcr4
[   20.190999359,5] STB: 0xFFFFFFFF measured to pcr0
[   20.249858153,5] STB: 0xFFFFFFFF measured to pcr1
[   20.308755622,5] STB: 0xFFFFFFFF measured to pcr2
[   20.367661007,5] STB: 0xFFFFFFFF measured to pcr3
[   20.426552422,5] STB: 0xFFFFFFFF measured to pcr4
[   20.485447381,5] STB: 0xFFFFFFFF measured to pcr5
[   21.032319621,5] STB: 0xFFFFFFFF measured to pcr6
[   21.091198804,5] STB: 0xFFFFFFFF measured to pcr7

root at p7pite01os:~# grep CAPP /sys/firmware/opal/msglog
[    3.270103949,7] FLASH: CAPP partition has ECC
[    3.271662223,7] FLASH: CAPP partition isn't signed
[    3.271663522,7] FLASH: flash subpartition eyecatcher CAPP
[    3.271665111,7] FLASH: CAPP partition actual size 0xa000
[    3.285369745,6] STB: CAPP sha512 hash calculated
[    3.354563470,5] STB: CAPP measured to pcr2
[    3.355374339,6] CHIP0: CAPP ucode lid loaded at 0x304c10e0
[    9.479082713,6] CHIP0: CAPP ucode lid loaded at 0x304c10e0
[   12.470828639,6] CHIP0: CAPP ucode lid loaded at 0x304c10e0

root at p7pite01os:~# grep BOOTKERNEL /sys/firmware/opal/msglog
[    3.357342668,7] FLASH: BOOTKERNEL partition doesn't have ECC
[    3.358726147,7] FLASH: BOOTKERNEL partition isn't signed
[    3.358727518,7] FLASH: BOOTKERNEL partition actual size 0xecb958
[   13.313564911,6] STB: BOOTKERNEL sha512 hash calculated
[   13.372513439,5] STB: BOOTKERNEL measured to pcr4

Thanks,

--
Claudio

On 10/24/2016 08:56 AM, Stewart Smith wrote:
> Claudio Carvalho <cclaudio at linux.vnet.ibm.com> writes:
>> The FFS API is not properly setting the part_actual (partition used
>> space) for the PNOR partitions at build time. However, skiboot needs
>> that to download and consequently measure and verify only the partition
>> used space. Currently, the FFS API is setting part_actual=part_size.
>>
>> This changes the flash_load_resource() to manually calculate the
>> part_actual for the requested partition in order to verify and measure
>> only the partition used space.
>>
>> Signed-off-by: Claudio Carvalho <cclaudio at linux.vnet.ibm.com>
> 
> I'm getting a problem with unsigned CAPP partition:
> 
> / # grep CAPP /sys/firmware/opal/msglog 
> [    4.340500052,7] FLASH: CAPP partition has ECC
> [    4.342002343,7] FLASH: CAPP partition isn't signed
> [    4.342003640,7] FLASH: flash subpartition eyecatcher CAPP
> [    4.342005055,7] FLASH: CAPP partition actual size 0xa000
> [    7.076642996,6] CHIP0: CAPP ucode lid loaded at 0x304ca0e0
> [    7.076644359,3] PHB#0000: CAPP: ucode header invalid
> [    8.114173972,6] CHIP0: CAPP ucode lid loaded at 0x304ca0e0
> [    8.114175323,3] PHB#0001: CAPP: ucode header invalid
> [    8.480692110,6] CHIP8: CAPP ucode lid loaded at 0x304ca0e0
> [    8.480693424,3] PHB#0020: CAPP: ucode header invalid
> [    9.437166081,6] CHIP8: CAPP ucode lid loaded at 0x304ca0e0
> [    9.437167411,3] PHB#0021: CAPP: ucode header invalid
> [   10.271371457,6] CHIP8: CAPP ucode lid loaded at 0SOL session closed by BMC
> 
> and yes, I have gotten "SOL session closed by BMC" due to the wonders of
> AMI BMC. I have gotten it around 20 times an hour ALL DAY trying to
> debug this.
> 