[U-Boot] 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,
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
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
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
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
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
participants (3)
-
Bin Meng -
Markus Valentin -
Simon Glass