Hi,
On 8 May 2014 23:12, Heiko Schocher hs@denx.de wrote:
Hello Mike,
Am 08.05.2014 15:02, schrieb mike:
Hi Heiko,
Did you see my last email? The one that bounced with a mime header and where I attached a patch file.
Seems I missed this EMail ...
I just wonder if its not better to switch the define to be
if (CONFIG_SIGNATURE_VERIFICATION_WITH_LEGACY_SIDE_DOOR). It can become mutually exclusive with the existing signature verification define.
The define length seems a little long, but this is also an option. I just prepared my patch after Simons comment, see:
I agree that it might be dangerous to allow legacy boot when signature verification is used. It would be nice to fix that.
Ideally we could have something like CONFIG_IMAGE_LEGACY to enable the legacy feature. We would need to enable it for most boards though. Also it breaks the rule of changing the behaviour of existing features. CONFIG_IMAGE_NO_LEGACY?
A rather more convoluted approach might be something awful like this in config_defaults:
#ifdef CONFIG_FIT_SIGNATURE_VERIFICATION # ifdef CONFIG_IMAGE_LEGACY_SIDE_DOOR # define CONFIG_IMAGE_LEGACY # endif #else #define CONFIG_IMAGE_LEGACY #endif
This means that legacy is on by default, unless signature verification is enabled, in which case the default flips. But I worry that it might only confuse people. This seems like a Wolfgang / Tom question :-)
That way the legacy stuff is removed automatically upon requesting verification unless defined otherwise. When you fail to boot an unsigned legacy kernel then its kind of obvious that you have to solve something but if you implement verified boot and forget this new variable then you leave a security hole.
In my last email I also discussed my confusion regard the 'required' variable. Similar argument to the above plus some other thoughts.
Was this EMail on the U-Boot ML? I could not find it... Can you send a link?
bye, Heiko
Regards, SImon