Hi Markus, On 20 February 2017 at 02:10, Markus Valentin <m...@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 <m...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot