booting signed Images
Hello Simon,
just talked with Wolfgang about the booting process from signed images, as it is described in:
doc/uImage.FIT/verified-boot.txtdoc/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
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.txtdoc/uImage.FIT/signature.txtIf we see it correct, then it is still possible to boot an uImage or a FIT image without signature with "bootm" when
CONFIG_FIT_SIGNATUREis 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_SIGNATUREis 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
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_SIGNATUREis 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.
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_SIGNATUREis 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
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 forIMAGE_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.
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_SIGNATUREis 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 forIMAGE_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
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_SIGNATUREis 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 forIMAGE_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_SIGNATUREto disable it?I prefer to check
CONFIG_FIT_SIGNATURE, and disableIMAGE_FORMAT_LEGACYcomplete.
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