On Mon, 05 Jun 2006 14:27:25 +0530, Wolfgang Denk wd@denx.de wrote:
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...
Thanks, I was trying to achieve something like this (as mentioned in the example) => bootm $addr1 || bootm $addr2 || tftpboot $loadaddr $loadfile && bootm
My technique was totally redundant and this sure is a more graceful way to accompalish the same.
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.
The board on which I am working on shall be shipped as a small module to a big product. Even though the buyer of the product shall be the owner of the board, the warranty shall cease to exist if some one actually replaces the boot-loader. Secondly we don't want our clients to replace our firmware with any other firmware which may actually cause wrong behavior and may affect our goodwill or cause problems to them due to the nature of the product.
I can understand that there are way to bypass and its not exactly fool-proof mechanism. I believe signing (PKI) the firmware would help in this regard. Giving source code is not an issue at all for me as private key shall still remain with us.
The only issue i see for now is that the image header structure won't accomodate the Digital signature string i.e. "image_header_t" and it has to be appended at the end of the firmware data blob.
Please let me know your views or how PKI implementation can be best done. I am planning to add the Digital signature at the end of the firmware data blob before generating the header.
We shall be updating the boot-loader and shall distribute the source code with our product.
If I own the hardware, I have every right to run any software I like on it.
Due the nature of the product this is possible but than again the warranty would void if some one updates the software by themselves.
Best Regards, rohit sharma