| Message ID | 20190729014430.30937-1-stewart@linux.ibm.com |
|---|---|
| Headers | show |
| Series | Use real Container Verification Code in Mambo | expand |
On Mon, Jul 29, 2019 at 11:45 AM Stewart Smith <stewart@linux.ibm.com> wrote: > > Secure Boot (for firmware) on POWER9 uses an in-memory copy of the > Container Verification Code (CVC), which the source comes from hostboot, > and the data structure is set up as part of early boot in the SBE and > Hostboot. > > Prior to this patchset, the way we simulated secure boot was to have a > "fake" securerom that was really just calling mbedtls sha512 and > comparing the hashes. This worked Well Enough(TM) for P8 and P9 testing, > but didn't reflect the guts of what would happen on real hardware. > > This patchset grabs a dump of the CVC code from a real machine set up > for development keys, and we can thus make the *exact* same calls into > it as what occurs on real hardware. > > The CVC code is imported as a blob rather the source from > hostboot/src/securerom and the various bits of setup mostly for > maintaining one's sanity. > > This also will help in the testing of the mmu patchset as for some > reason when we enter the CVC code we clear r2, which adds a bit of fun > and adventure to the whole endeavour. series merged to master as 12610da1bacf3578849eefe8f8d70cc289f4b87a I squashed patch 2 into 3 and truncated the trailing zero bytes from the cvc blob too. > > Stewart Smith (3): > libstb: export CVC/securerom code memory range > Add CVC code dump for use with Mambo > mambo: enable use of real Container Verification Code > > external/mambo/CVC | Bin 0 -> 65535 bytes > external/mambo/README.md | 11 +++ > external/mambo/skiboot.tcl | 70 +++++++++++++++++-- > libstb/cvc.c | 21 +++++- > test/hello_world/run_mambo_p9_hello_world.sh | 1 + > test/sreset_world/run_mambo_p9_sreset.sh | 1 + > 6 files changed, 97 insertions(+), 7 deletions(-) > create mode 100644 external/mambo/CVC > > -- > 2.21.0 > > _______________________________________________ > Skiboot mailing list > Skiboot@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/skiboot
On Wed, Nov 27, 2019, at 6:37 PM, Oliver O'Halloran wrote: > On Mon, Jul 29, 2019 at 11:45 AM Stewart Smith <stewart@linux.ibm.com> wrote: > > > > Secure Boot (for firmware) on POWER9 uses an in-memory copy of the > > Container Verification Code (CVC), which the source comes from hostboot, > > and the data structure is set up as part of early boot in the SBE and > > Hostboot. > > > > Prior to this patchset, the way we simulated secure boot was to have a > > "fake" securerom that was really just calling mbedtls sha512 and > > comparing the hashes. This worked Well Enough(TM) for P8 and P9 testing, > > but didn't reflect the guts of what would happen on real hardware. > > > > This patchset grabs a dump of the CVC code from a real machine set up > > for development keys, and we can thus make the *exact* same calls into > > it as what occurs on real hardware. > > > > The CVC code is imported as a blob rather the source from > > hostboot/src/securerom and the various bits of setup mostly for > > maintaining one's sanity. > > > > This also will help in the testing of the mmu patchset as for some > > reason when we enter the CVC code we clear r2, which adds a bit of fun > > and adventure to the whole endeavour. > > series merged to master as 12610da1bacf3578849eefe8f8d70cc289f4b87a > > I squashed patch 2 into 3 and truncated the trailing zero bytes from > the cvc blob too. Ahh cool. If I was Really Good (TM) I would have built from source from a copy of what's in Hostboot and blah blah blah, but this is probably as good as anything from a practical PoV. I wonder why they just expose the full 64k and not truncate it down...
On Fri, Nov 29, 2019 at 7:19 AM Stewart Smith <stewart@flamingspork.com> wrote: > > On Wed, Nov 27, 2019, at 6:37 PM, Oliver O'Halloran wrote: > > On Mon, Jul 29, 2019 at 11:45 AM Stewart Smith <stewart@linux.ibm.com> wrote: > > > > > > Secure Boot (for firmware) on POWER9 uses an in-memory copy of the > > > Container Verification Code (CVC), which the source comes from hostboot, > > > and the data structure is set up as part of early boot in the SBE and > > > Hostboot. > > > > > > Prior to this patchset, the way we simulated secure boot was to have a > > > "fake" securerom that was really just calling mbedtls sha512 and > > > comparing the hashes. This worked Well Enough(TM) for P8 and P9 testing, > > > but didn't reflect the guts of what would happen on real hardware. > > > > > > This patchset grabs a dump of the CVC code from a real machine set up > > > for development keys, and we can thus make the *exact* same calls into > > > it as what occurs on real hardware. > > > > > > The CVC code is imported as a blob rather the source from > > > hostboot/src/securerom and the various bits of setup mostly for > > > maintaining one's sanity. > > > > > > This also will help in the testing of the mmu patchset as for some > > > reason when we enter the CVC code we clear r2, which adds a bit of fun > > > and adventure to the whole endeavour. > > > > series merged to master as 12610da1bacf3578849eefe8f8d70cc289f4b87a > > > > I squashed patch 2 into 3 and truncated the trailing zero bytes from > > the cvc blob too. > > Ahh cool. If I was Really Good (TM) I would have built from source from a copy of what's in Hostboot and blah blah blah, but this is probably as good as anything from a practical PoV. > > I wonder why they just expose the full 64k and not truncate it down... Hostboot aligns the start and end of all the memory reservations to 64K boundaries since the kernel assumes that some of them (i.e. the ones PRD uses) can be mmap()ed. Strictly speaking they don't need to for the CVC, but aligning everything is probably just easier for all involved.