[Skiboot] [RFC PATCH 0/3] WIP VMM for OPAL boot
stewart at linux.ibm.com
Tue Jun 11 11:09:45 AEST 2019
Nicholas Piggin <npiggin at gmail.com> writes:
> Stewart Smith's on June 7, 2019 7:56 am:
>> Stewart Smith <stewart at linux.ibm.com> writes:
>>> Nicholas Piggin <npiggin at gmail.com> writes:
>>>> This is my current work in progress, I've gradually been adding bits
>>>> and fixing bugs so time for another rebase. It's been booting pretty
>>>> reliably on my P9, I've next been trying to bring VMM mode back up
>>>> when we fast-reboot which is still a bit buggy but almost works.
>>> Cool. I'm chasing the secure boot problems, which has now become "get
>>> all the genuine secure "rom" stuff running in Mambo".
>>> This is the most obivous "Something is going to go wrong without it" bit
>>> I have, but that doesn't magically fix things, nor explain why
>>> everything stops suddenly.
>> As mentioned on slack, I found the problem was that we had a "li %r2,0"
>> in the mix.
>> The Container Verification Code is a blob that we get passed in from
>> hostboot (well, all the way from the hostboot bootloader actually) that
>> has two entry points: one for validating a secureboot header and the
>> other for computing sha512 checksum of a blob.
>> In skiboot, the libstb/cvc.c code finds it, which on P9 is from a
>> reserved memory region, and on P8 it's by copying it from an actual ROM
>> that's on chip that needs to be accessed with cache inhibited reads.
>> The asm/cvc_entry.S wrapper, as part of calling the CVC function, sets
>> %r2 to zero. Thus, when we take the ISI for the page of text, we end up
>> in vm_isi() without %r2 set to anything sane, and we end up hitting the
>> assert(!_dw0) in htab_install because we're poking around where we're
>> not meant to. Naturally, all the (soon multiple levels) of
>> exception_entry() and abort() without a sane %r2 goes about as well as
>> you'd expect and we eventually xstop.
>> For at least a quick hack (I haven't thought about it beyond "hey, we're
>> not using that register") I stashed the skiboot TOC in HSPRG0 and pulled
>> it in in _exception.
>> So, the below patch is on top of this series that (at least in Mambo, I
>> haven't tested on hardware yet), will run the CVC code and boot a
> Awesome, that r2 clobber was a good catch.
> I think we can make a separate patch that always loads up
> the skiboot r2 in the exception path (preserving the original),
> which will also prevent bad crashes anywhere else that r2 is
> modified on purpose or by mistake.
Yeah, I hit a bad r2 again in the fast reboot path with my hack, as of
course linux used HSPRG0
>> I'm not sure what's up with my mambo tcl to ensure I get the
>> references/size right for the CVC code in the device tree, so have
>> quickly hacked around it with a if (size==0) size = 64*1024 in cvc.c
>> (maybe the Masters of Mambo can enlighten me).
> What are you doing there, is that creating a CVC blob that actually
> runs when you boot mambo?
Yeah, I grabbed one from a running machine (just dumped out the memory
range of it) and loaded it up in Mambo. We could also compile our own I
believe, the securerom code in Hostboot doesn't need a complex makefile.
OPAL Architect, IBM.
More information about the Skiboot