[Skiboot] [PATCH v2 00/20] libstb: add support for secure and trusted boot in P9

[Stewart Smith]

Claudio Carvalho <cclaudio at linux.vnet.ibm.com> writes:
> On 13/12/2017 07:54, Stewart Smith wrote:
>> Claudio Carvalho <cclaudio at linux.vnet.ibm.com> writes:
>>> / # grep STB /sys/firmware/opal/msglog
>>> [    2.418837830,5] STB: Found ibm,secureboot-v2
>>> [    2.422842040,5] STB: secure mode on (FORCED by nvram)
>>> [    2.425680374,6] STB: Found CVC @ 3ffd320000-3ffd32ffff
>>> [    2.425681636,6] STB: Found CVC-sha512 @ 3ffd320040, version=1
>>> [    2.425682890,6] STB: Found CVC-verify @ 3ffd320050, version=1
>>> [    2.425685891,5] STB: trusted mode on
>>> [    2.427116155,5] STB: Found tpm0,i2c_tpm_nuvoton evLogLen=2174 evLogSize=65536
>>> [    3.037325656,6] STB: IMA_CATALOG verified
>>> [    3.037483524,6] STB: IMA_CATALOG hash calculated
>>> [    3.080420989,5] STB: IMA_CATALOG measured on pcr2 (tpm0, evType 0x5, evLogLen 2257)
>>> [    3.221401794,6] STB: CAPP verified
>>> [    3.221641991,6] STB: CAPP hash calculated
>>> [    3.264593590,5] STB: CAPP measured on pcr2 (tpm0, evType 0x5, evLogLen 2333)
>>> [    8.427545176,6] STB: BOOTKERNEL verified
>>> [    8.459509213,6] STB: BOOTKERNEL hash calculated
>>> [    8.502478342,5] STB: BOOTKERNEL measured on pcr4 (tpm0, evType 0x5, evLogLen 2415)
>>> [    9.317683588,5] STB: EV_SEPARATOR measured on pcr0 (tpm0, evType 0x4, evLogLen 2491)
>>> [    9.364162692,5] STB: EV_SEPARATOR measured on pcr1 (tpm0, evType 0x4, evLogLen 2567)
>>> [    9.410932645,5] STB: EV_SEPARATOR measured on pcr2 (tpm0, evType 0x4, evLogLen 2643)
>>> [    9.457221555,5] STB: EV_SEPARATOR measured on pcr3 (tpm0, evType 0x4, evLogLen 2719)
>>> [    9.503811698,5] STB: EV_SEPARATOR measured on pcr4 (tpm0, evType 0x4, evLogLen 2795)
>>> [   10.038662929,5] STB: EV_SEPARATOR measured on pcr5 (tpm0, evType 0x4, evLogLen 2871)
>>> [   10.085016642,5] STB: EV_SEPARATOR measured on pcr6 (tpm0, evType 0x4, evLogLen 2947)
>>> [   10.131638410,5] STB: EV_SEPARATOR measured on pcr7 (tpm0, evType
>>> 0x4, evLogLen 3023)
>> I'm having a slightly different experience at the moment:
>>
>> I used sb-signing-utils to ./sign-with-local-keys.sh (using the development keys
>> in op-build/openpower/package/sb-signing-utils/keys) for BOOTKERNEL, and
>> I'm instead just getting:
>> [   51.147186780,0] STB: VERSION NOT VERIFIED, invalid param. buf=0x30575560, len=4096 key-hash=0x0 hash-size=0
>> [   51.254853202,5] STB: Found ibm,secureboot-v2
>> [   51.258769416,5] STB: secure mode off
>> [   51.260898690,6] STB: Found CVC @ 3ffd2e0000-3ffd2effff
>> [   51.260899992,6] STB: Found CVC-sha512 @ 3ffd2e0040, version=1
>> [   51.260901467,6] STB: Found CVC-verify @ 3ffd2e0050, version=1
>> [   51.260904595,5] STB: trusted mode off
>> [   51.373418060,0] STB: IMA_CATALOG verification FAILED. log=0xffffffffffff8160
>> [   51.502378419,0] STB: CAPP verification FAILED. log=0xffffffffffff8160
>> [   57.131768572,0] STB: BOOTKERNEL verification FAILED. log=0xffffffffffff8160
>
> I'm not sure if the problem is in skiboot libstb AND/OR on how the PNOR 
> image was generated/signed. How can I reproduce it? p9dsu or
> witherspoon?

This was on p9dsu, upstream op-build with the hostboot p9dsu config
changed as I mentioned. For signing the BOOTKERNEL, I used the
sb-sign-utils to just sign that partition.

Additionally, my patch I mentioned before where I ran the verification
no matter what was also present.

Maybe there's hostboot code missing upstream? or some XML change that's missing?

> FYI. In order to test this patch series on p9dsu I had to use a PNOR 
> image provided by SMC.
> op-build upstream doesn't have all the bits required to test the patch 
> series.

What's missing?

> The major point that concerns me in this log is that skiboot is 
> verifying the signature of all firmware blobs even when the system is 
> booting in non-secure mode ("STB: secure mode off"). In a normal 
> situation, the verification should be performed only when the system is 
> booting in secure mode. There is a secure_mode check at the beginning of 
> the secureboot_verify() function to ensure that.

yeah, that's my patch to make it do that, I didn't want to wake somebody
up in the lab to go pull a jumper :)

> The log=0xffffffffffffff8160 message means that hardware key hash check 
> failed. In other words, the hw-key-hash in the container doesn't match 
> with the hw-key-hash that skiboot provided to the CVC (Container 
> Verification Code).

Hrm.. I wonder what it provided and where it got it from. There's
probably a bunch of missing pieces here, just trying to narrow them down.


-- 
Stewart Smith
OPAL Architect, IBM.