[U-Boot] x86: SecureBoot: Bay Trail

[Simon Glass]

Hi,

On 22 February 2017 at 02:58, Markus Valentin <mv at denx.de> wrote:
> Hi Simon,
>
> On Tue, 2017-02-21 at 20:59 -0700, Simon Glass wrote:
>> 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.
> Thanks a lot for the clarification :)
>>
>> 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?
> No i'm not able to change the size of the image that gets verified by the TXE.
>>
>> 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
> That is exactly what im targeting at.
>
> Luckily i have 400 bytes of arbitrary usable data (OEM-Data-Region) which is
> already authenticated by the hardware (it is inside the SecureBootManifest).
>
> My current idea is to put a checksum over u-boot+u-boot-dtb+ucode (as assembled
> via binman) inside the oem-block. Then i need to compare the stored checksum(s)
> with the at runtime calculated one(s). This would make sure that my u-boot code
> has not been tampered.
>
> So i need to get my verification piece in the start stage as you said. Am i
> right that start stage is equal to u-boot-x86-16bit.bin aka "x86-start16" for
> binman input?
>
> If i have accomplished that, and compared the checksum(s), u-boot has been
> completely verified. Afterwards i can go on and use the fit-mechanism for the
> rest of the boot process.
>
> Please correct me if i miss something or you think something should be done
> differently i'm looking forward your feedback.

That sounds fine, but of course you need to make sure that the code
that checks the checksum is itself protected against modification.

>>
>>  - Use SPL, a bit like 64-bit U-Boot, except that U-Boot proper is
>> x32-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
> I will save that idea if i get a tough problem with my initial idea.
>>
>> >
>> > >
>> > >
>> > > >
>> > > >
>> > > >
>> > > > Intel provides a manual o1n 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.
>>
>
> best regards
>
> Markus


Regards,
Simon