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