* [U-Boot] x86: SecureBoot: Bay Trail @ 2017-02-17 9:26 Markus Valentin 2017-02-17 11:58 ` Bin Meng 0 siblings, 1 reply; 6+ messages in thread From: Markus Valentin @ 2017-02-17 9:26 UTC (permalink / raw) To: u-boot 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.? 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. How can i get the equivalent for the coreboot-ramstage from U-Boot? Best regards? Markus ^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] x86: SecureBoot: Bay Trail 2017-02-17 9:26 [U-Boot] x86: SecureBoot: Bay Trail Markus Valentin @ 2017-02-17 11:58 ` Bin Meng 2017-02-20 9:10 ` Markus Valentin 0 siblings, 1 reply; 6+ messages in thread From: Bin Meng @ 2017-02-17 11:58 UTC (permalink / raw) To: u-boot Hi Markus, On Fri, Feb 17, 2017 at 5:26 PM, Markus Valentin <mv@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? > > 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? > 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. Regards, Bin ^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] x86: SecureBoot: Bay Trail 2017-02-17 11:58 ` Bin Meng @ 2017-02-20 9:10 ` Markus Valentin 2017-02-22 3:59 ` Simon Glass 0 siblings, 1 reply; 6+ messages in thread From: Markus Valentin @ 2017-02-20 9:10 UTC (permalink / raw) To: u-boot 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@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). > > > > > > > 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.? best regards Markus ^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] x86: SecureBoot: Bay Trail 2017-02-20 9:10 ` Markus Valentin @ 2017-02-22 3:59 ` Simon Glass 2017-02-22 9:58 ` Markus Valentin 0 siblings, 1 reply; 6+ messages in thread From: Simon Glass @ 2017-02-22 3:59 UTC (permalink / raw) To: u-boot Hi Markus, On 20 February 2017 at 02:10, Markus Valentin <mv@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@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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] x86: SecureBoot: Bay Trail 2017-02-22 3:59 ` Simon Glass @ 2017-02-22 9:58 ` Markus Valentin 2017-03-03 4:52 ` Simon Glass 0 siblings, 1 reply; 6+ messages in thread From: Markus Valentin @ 2017-02-22 9:58 UTC (permalink / raw) To: u-boot Hi Simon, On Tue, 2017-02-21 at 20:59 -0700, Simon Glass wrote: > On 20 February 2017 at 02:10, Markus Valentin <mv@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@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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] x86: SecureBoot: Bay Trail 2017-02-22 9:58 ` Markus Valentin @ 2017-03-03 4:52 ` Simon Glass 0 siblings, 0 replies; 6+ messages in thread From: Simon Glass @ 2017-03-03 4:52 UTC (permalink / raw) To: u-boot Hi, On 22 February 2017 at 02:58, Markus Valentin <mv@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@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@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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-03-03 4:52 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-02-17 9:26 [U-Boot] x86: SecureBoot: Bay Trail Markus Valentin 2017-02-17 11:58 ` Bin Meng 2017-02-20 9:10 ` Markus Valentin 2017-02-22 3:59 ` Simon Glass 2017-02-22 9:58 ` Markus Valentin 2017-03-03 4:52 ` Simon Glass
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox