From: Rohit Sharma <rohits79@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] Secure Firmware + Firmware Upgrade?
Date: Mon, 05 Jun 2006 07:13:45 +0530 [thread overview]
Message-ID: <op.tange7swdfxu59@sys.t-mobile.de> (raw)
In-Reply-To: <20060602202449.22350353A57@atlas.denx.de>
On Sat, 03 Jun 2006 01:54:49 +0530, Wolfgang Denk <wd@denx.de> wrote:
> In message <586f5d00606020556s1940cd23seb0a8e7d67dc32a6@mail.gmail.com>
> you wrote:
>>
>> The bootcmd envrionment variable shall "cp the-boot-script-image from
>> flash to RAM" and
>> "bootm the-boot-script-image". The boot script image is not compressed.
>
> This is redundand. "bootm" includes loading the image to the load
> address. No extra copy is needed here.
>
>> Case 1: If the boot-bit flag is set, the boot-script shall copy the
>> image to RAM and check the signed/encrypted image for authenticity and
>> integrity (how this is done is yet to be identified)
>
> You can check the image in flash before running "bootm"
>
Thanks for the correction
>> Case 2: If the boot flag is not set the boot-loader shall
>> copy the new firmware image to a given address in RAM via kermit
>> protocol
>
> Copy from flash to RAM with kermit protocol? Either you omitted some
> vital information here, or this is fundamentally broken.
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
image
shall be saved to RAM.
>> erase the old kernel image at the given address
>> copy the new image from RAM to flash
>> finally save env so the new firmware is writable
>> set the boot-bit to boot from the new firmware
>
> 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.
The boot-script-image (which is set read-only) shall be the first image to
be loaded and
shall check to see if the firmware image is authentic or not i.e. only on
next boot?
Only when its type authentic shall it pass control to the main firmware
else fall back
to default working.
Am sorry if i wasn't clear in letting you explain the same before. Do you
still feel that its possible
to tamper and by pass the security unless ofcourse if boot-script-image is
manipulated?
Thanks for you kind help !!!
Best Regards,
rohit
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
next prev parent reply other threads:[~2006-06-05 1:43 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-02 12:56 [U-Boot-Users] Secure Firmware + Firmware Upgrade? Rohit
2006-06-02 20:24 ` Wolfgang Denk
2006-06-05 1:43 ` Rohit Sharma [this message]
2006-06-05 8:57 ` Wolfgang Denk
2006-06-05 6:10 ` Rohit Sharma
2006-06-05 7:53 ` Rohit Sharma
2006-06-05 13:09 ` Wolfgang Denk
2006-06-05 9:51 ` Rohit Sharma
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=op.tange7swdfxu59@sys.t-mobile.de \
--to=rohits79@gmail.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox