[U-Boot] x86: SecureBoot: Bay Trail

[Simon Glass]

Hi Markus,

On 20 February 2017 at 02:10, Markus Valentin <mv at denx.de> wrote:
> Hi,
>
> On Fri, 2017-02-17 at 19:58 +0800, Bin Meng wrote:
>> On Fri, Feb 17, 2017 at 5:26 PM, Markus Valentin <mv at denx.de> wrote:
>> >
>> > Hi,
>> >
>> > i'm implementing Secure Boot with U-Boot on a Intel Atom E3800 Series (Bay
>> > Trail) based Plattform.
>> >
>> > I did manage to get the first boot stage (Initial Boot Block) verified by
>> > the
>> > Trusted Execution Engine, next i need to verify the "ramstage" as they call
>> > it.
>>
>> How did you implement the first boot stage? Is it U-Boot SPL?
> No, i'm not using SPL, but maybe i should?
>
> Currently i follow the instructions from document #558081 "Enabling Secure Boot
> with Intel FSP and coreboot" for Intel ® Atom TM Processor E3800 Product
> Family".
> There they state that i should extract a IBB(Initial Boot Block) which is the
> last 127Kib from the u-boot.rom/coreboot.rom file. IBB plus a secure boot
> "manifest" is the 1st stage that gets properly authenticated, copied to ram
>  and executed(128Kib).

Coreboot has the concepts of:

boot block - run first, handles boot vector 16-bit to 32-bit
transition, sets up cache-as-RAM (CAR) and other early things, then
starts romstage
romstage - runs using CAR as stack, sets up SDRAM, starts  ramstage
ramstage - the rest of coreboot

These are actually three separate programs, individually compiled and
linked, even through they are actually packaged into the same ROM.

In 32-bit U-Boot we build U-Boot as one program. It goes through these stages:

start - handles boot vector 16-bit to 32-bit transition, sets up
cache-as-RAM (CAR) and other early things
pre-relocation - runs using CAR as stack, sets up SDRAM, relocates
U-Boot into RAM, jumps there
post-relocation - the rest of U-Boot

Note: For 64-bit U-Boot we do in fact build two images: roughly
speaking, SPL runs in 32-bit mode and does the first two steps above
then loads U-Boot proper into RAM, changes to 64-bit mode and jumps to
it.

Back to your problem...I don't think you need to use SPL on 32-bit
x86. You should be able to set things up to verify the reset vector
and the entire U-Boot image. Can you adjust the size of the image that
is verified?

If you find that you cannot adjust this size to cover all of U-Boot,
then I see two options:

- Add a verification piece which runs immediately after the 'start'
stage above, and performs the crypto verification using U-Boot's FIT
system. This will involve linking all of the required code into a
single block which is covered by the chip's verification

- Use SPL, a bit like 64-bit U-Boot, except that U-Boot proper is
32-bit. Then you can use the chip's verification to verify SPL, and
SPL's verification to load and verify U-Boot proper and anything else
you need

>>
>> >
>> >
>> > Intel provides a manual on how to enable Secure Boot with coreboot in this
>> > manual they extract the "ramstage" from the coreboot.rom file via cbfs.
>> >
>>
>> Which manual is this?
> #558081 "Enabling Secure Boot with Intel FSP and coreboot" for Intel ® Atom TM
> Processor E3800 Product Family"
>>
>> >
>> > How can i get the equivalent for the coreboot-ramstage from U-Boot?
>> >
>>
>> My understanding is that since you already managed to have the
>> hardware (TXE) successfully verify the first boot stage, the next step
>> is all yours, which means you don't need anything like
>> coreboot-ramstage. You can implement whatever loading/authenticating
>> mechanism you put in the first boot stage to boot the 2nd stage.
> Thats a good point, thanks. I already implemented verification in U-Boot for
> verification of the fit-image public-key, so i could easily adopt it.

Regards,
Simon