Hi Simon, On Tue, 2017-02-21 at 20:59 -0700, Simon Glass wrote: > 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. 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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
