In message op.tange7swdfxu59@sys.t-mobile.de you wrote:
Sorry for not being verbose, here I meant that if the boot bit flag is not set it would imply that the firmware upgrade failed and its not safe to boot. It would than wait to load the firmware via kermit protocol. This
In which way not safe? We have pretty good image protection using CRC checksums. What sort of additional security do you want to gain with this additional bit? I don't understand...
You are aware that this is not really secure in any way, as it leaves many ways to run random unsigned images, too?
In my case the firmware upgrade is not secure that is my requirement is > > not to check if the firmware being replaced is authentic or not, it is the signed > firmware that matters.
Your product will include GPLed boot loader., i. e. you must accompany it with a written offer to give any third party a complete copy of the corresponding source code. If I want to run my own code I will just disable the "authenticity tests" in U-Boot and install my own, free boot loader. Or I'll craft an image that passes your tests.
Am sorry if i wasn't clear in letting you explain the same before. Do yo> u > still feel that its possible to tamper and by pass the security unless ofcourse if boot-script-image > is > manipulated?
Yes of course it is possible to boot my own custom images. There are several ways to do this. And I intentionally avoid the term "tampered" here, because it does not apply. If I own the hardware, I have every right to run any software I like on it.
Best regards,
Wolfgang Denk