x86: SecureBoot: Bay Trail
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
Hi Markus,
Quoted 8 lines · Markus Valentin
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?
Quoted 4 lines
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?
Quoted 2 lines
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
Hi,
Quoted 7 lines · Bin Meng
Quoted 6 lines · Markus Valentin
Hi,
i'm implementing Secure Boot with U-Boot on a Intel Atom E3800 Series (Bay Trail) based Plattform.
Quoted 6 lines
Quoted 4 lines
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).
Quoted 8 lines
Quoted 6 lines
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"
Quoted 10 lines
Quoted 4 lines
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
Hi Markus,
Quoted 18 lines · Markus Valentin
Hi,
Quoted 7 lines · Bin Meng
Quoted 6 lines · Markus Valentin
Hi,
i'm implementing Secure Boot with U-Boot on a Intel Atom E3800 Series (Bay Trail) based Plattform.
Quoted 6 lines
Quoted 4 lines
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?
Quoted 7 lines
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
Quoted 15 lines
Quoted 8 lines
Quoted 6 lines
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"
Quoted 5 lines
Quoted 4 lines
How can i get the equivalent for the coreboot-ramstage from U-Boot?
Quoted 7 lines
Quoted 5 lines
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
Hi Simon,
Quoted 55 lines · Simon Glass
Quoted 24 lines · Markus Valentin
Hi,
Quoted 10 lines · Bin Meng
Quoted 8 lines · Markus Valentin
Hi,
i'm implementing Secure Boot with U-Boot on a Intel Atom E3800 Series (Bay
Trail) based Plattform.Quoted 8 lines
Quoted 6 lines
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?
Quoted 9 lines
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 corebootThese 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
Quoted 4 lines
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 :)
Quoted 5 lines
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.?
Quoted 8 lines
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.
Quoted 5 lines
?- 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.
Quoted 23 lines
Quoted 23 lines
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
Quoted 4 lines
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"Quoted 7 lines
Quoted 6 lines
How can i get the equivalent for the coreboot-ramstage from U-Boot?
Quoted 9 lines
Quoted 8 lines
Quoted 5 lines
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
Hi,
Quoted 91 lines · Markus Valentin
Hi Simon,
Quoted 55 lines · Simon Glass
Quoted 24 lines · Markus Valentin
Hi,
Quoted 10 lines · Bin Meng
Quoted 8 lines · Markus Valentin
Hi,
i'm implementing Secure Boot with U-Boot on a Intel Atom E3800 Series (Bay
Trail) based Plattform.Quoted 8 lines
Quoted 6 lines
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?
Quoted 9 lines
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 corebootThese 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-BootQuoted 4 lines
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 :)
Quoted 5 lines
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.
Quoted 8 lines
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?
Quoted 6 lines
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.
Quoted 34 lines
Quoted 5 lines
- 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 needI will save that idea if i get a tough problem with my initial idea.
Quoted 28 lines
Quoted 28 lines
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
Quoted 4 lines
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"Quoted 12 lines
Quoted 6 lines
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.
Quoted 8 lines
Quoted 4 lines
Quoted 3 lines
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