[U-Boot] x86: SecureBoot: Bay Trail

[Markus Valentin]

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.
> 
>  - 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