Skip to contentSkip to conversation

booting signed Images

U-Boot Heiko Schocher 3 participants 7 messages May 5, 2014 – May 7, 2014

lore
Share & tools
lore
#0 lore raw

Hello Simon,

just talked with Wolfgang about the booting process from signed images, as it is described in:

doc/uImage.FIT/verified-boot.txt
doc/uImage.FIT/signature.txt

If we see it correct, then it is still possible to boot an uImage or a FIT image without signature with "bootm" when CONFIG_FIT_SIGNATURE is defined.

The question raised, if this is a good behaviour.

Should we not prevent booting uImages or not signed FIT Images when CONFIG_FIT_SIGNATURE is defined?
Or at least prevent booting such unsigned images through an U-Boot env variable.

What Do you think?

Thanks in advance

bye,
Heiko

Signature · 2 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
#1 lore raw

HI Heiko,

Quoted 12 lines · Heiko Schocher

Hello Simon,

just talked with Wolfgang about the booting process from signed images, as it is described in:

doc/uImage.FIT/verified-boot.txt
doc/uImage.FIT/signature.txt

If we see it correct, then it is still possible to boot an uImage or a FIT image without signature with "bootm" when CONFIG_FIT_SIGNATURE is defined.

Quoted 8 lines

The question raised, if this is a good behaviour.

Should we not prevent booting uImages or not signed FIT Images when CONFIG_FIT_SIGNATURE is defined?
Or at least prevent booting such unsigned images through an U-Boot env variable.

What Do you think?

There is a 'required' property in the public keys which is intended to support this. If you mark a key as 'required then it will need to be verified by any image that is loaded. There is a test for this case, but it may not be comprehensive.

Regards,
Simon

#2 lore raw

Dear Simon,

Quoted 6 lines · In message <CAPnjgZ2-qC8YK8t2DvmzXWKy3Wd+=7VY1Ti=Jm98LF96PLfu-g@mail.gmail.com>…
Quoted 6 lines

Should we not prevent booting uImages or not signed FIT Images when CONFIG_FIT_SIGNATURE is defined?
Or at least prevent booting such unsigned images through an U-Boot env variable.

Quoted 6 lines
Quoted 1 line

What Do you think?

There is a 'required' property in the public keys which is intended to support this. If you mark a key as 'required then it will need to be verified by any image that is loaded. There is a test for this case, but it may not be comprehensive.

But what about legacy uImage files? It appears nothing would stop booting one of those?

Best regards,

Wolfgang Denk

Signature · 5 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Accident: A condition in which presence of mind is good, but  absence
of body is better.
#3 lore raw

Hi Wolfgang,

Quoted 11 lines · Wolfgang Denk

Dear Simon,

Quoted 8 lines · In message <CAPnjgZ2-qC8YK8t2DvmzXWKy3Wd+=7VY1Ti=Jm98LF96PLfu-g@mail.gmail.com>…
Quoted 7 lines

Should we not prevent booting uImages or not signed FIT Images when CONFIG_FIT_SIGNATURE is defined?
Or at least prevent booting such unsigned images through an U-Boot env variable.

What Do you think?

Quoted 7 lines
Quoted 4 lines

There is a 'required' property in the public keys which is intended to support this. If you mark a key as 'required then it will need to be verified by any image that is loaded. There is a test for this case, but it may not be comprehensive.

But what about legacy uImage files? It appears nothing would stop booting one of those?

That's right, there is nothing to stop that at present. The verification happens either on each image (for per-image signing) or on the selected configuration as a whole (in fit_image_load() when it sees the kernel being loaded).

One simple solution might be to check a CONFIG option in boot_get_kernel() and disable support for IMAGE_FORMAT_LEGACY.

Regards,
Simon

#4 lore raw

Dear Simon,

Quoted 9 lines · In message <CAPnjgZ3OKQ8UZMOrQ7m7zWDWsFa2yZqCT2F69sKwgjDymOzePw@mail.gmail.com>…
Quoted 8 lines
Quoted 5 lines

There is a 'required' property in the public keys which is intended to support this. If you mark a key as 'required then it will need to be verified by any image that is loaded. There is a test for this case, but it may not be comprehensive.

But what about legacy uImage files? It appears nothing would stop booting one of those?

Quoted 7 lines

That's right, there is nothing to stop that at present. The verification happens either on each image (for per-image signing) or on the selected configuration as a whole (in fit_image_load() when it sees the kernel being loaded).

One simple solution might be to check a CONFIG option in boot_get_kernel() and disable support for IMAGE_FORMAT_LEGACY.

This makes sense to me. Thanks!

Best regards,

Wolfgang Denk

Signature · 4 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I haven't lost my mind -- it's backed up on tape somewhere.
#5 lore raw
In reply to Simon Glass

Hello Simon,

Am 05.05.2014 20:31, schrieb Simon Glass:

Quoted 22 lines

Hi Wolfgang,

Quoted 11 lines · Wolfgang Denk

Dear Simon,

Quoted 8 lines · In message<CAPnjgZ2-qC8YK8t2DvmzXWKy3Wd+=7VY1Ti=Jm98LF96PLfu-g@mail.gmail.com>…
Quoted 7 lines

Should we not prevent booting uImages or not signed FIT Images when CONFIG_FIT_SIGNATURE is defined?
Or at least prevent booting such unsigned images through an U-Boot env variable.

What Do you think?

Quoted 7 lines
Quoted 4 lines

There is a 'required' property in the public keys which is intended to support this. If you mark a key as 'required then it will need to be verified by any image that is loaded. There is a test for this case, but it may not be comprehensive.

But what about legacy uImage files? It appears nothing would stop booting one of those?

Quoted 7 lines

That's right, there is nothing to stop that at present. The verification happens either on each image (for per-image signing) or on the selected configuration as a whole (in fit_image_load() when it sees the kernel being loaded).

One simple solution might be to check a CONFIG option in boot_get_kernel() and disable support for IMAGE_FORMAT_LEGACY.

The question is here, do we introduce a new config option for this, or do we use for example CONFIG_FIT_SIGNATURE to disable it?

I prefer to check CONFIG_FIT_SIGNATURE, and disable IMAGE_FORMAT_LEGACY complete.

bye,
Heiko

Signature · 2 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
#6 lore raw

Hi Heiko,

Quoted 41 lines · Heiko Schocher

Hello Simon,

Am 05.05.2014 20:31, schrieb Simon Glass:

Hi Wolfgang,

Quoted 27 lines · Wolfgang Denk
Quoted 15 lines

Dear Simon,

In message<CAPnjgZ2-qC8YK8t2DvmzXWKy3Wd+=7VY1Ti=Jm

Quoted 9 lines · 98LF96PLfu-g at mail.gmail.com> you wrote:

Should we not prevent booting uImages or not signed FIT Images when

Quoted 6 lines

CONFIG_FIT_SIGNATURE is defined?
Or at least prevent booting such unsigned images through an U-Boot env variable.

What Do you think?

Quoted 9 lines
Quoted 5 lines

There is a 'required' property in the public keys which is intended to support this. If you mark a key as 'required then it will need to be verified by any image that is loaded. There is a test for this case, but it may not be comprehensive.

But what about legacy uImage files? It appears nothing would stop booting one of those?

Quoted 8 lines

That's right, there is nothing to stop that at present. The verification happens either on each image (for per-image signing) or on the selected configuration as a whole (in fit_image_load() when it sees the kernel being loaded).

One simple solution might be to check a CONFIG option in boot_get_kernel() and disable support for IMAGE_FORMAT_LEGACY.

Quoted 6 lines

The question is here, do we introduce a new config option for this, or do we use for example CONFIG_FIT_SIGNATURE to disable it?

I prefer to check CONFIG_FIT_SIGNATURE, and disable IMAGE_FORMAT_LEGACY complete.

I suggest a new CONFIG option, like CONFIG_DISABLE_IMAGE_FORMAT_LEGACY or possible a device tree option, since if you force disable of the legacy format you are actually removing functionality. At present CONFIG_FIT_SIGNATURE is a capability, and one capability should not normally preclude another.

Regards,
Simon