* [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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.