From: Wolfgang Denk <wd@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] Password protection of U-Boot command line
Date: Fri, 10 Feb 2012 14:27:38 +0100 [thread overview]
Message-ID: <20120210132738.AF0C714BC602@gemini.denx.de> (raw)
In-Reply-To: <4F3505F8.1070504@gmail.com>
Dear Graeme Russ,
In message <4F3505F8.1070504@gmail.com> you wrote:
>
> > We already have such protection, even if it's very simplistic: see
> > doc/README.autoboot (search for CONFIG_AUTOBOOT_DELAY_STR,
> > CONFIG_AUTOBOOT_STOP_STR resp. "bootdelaykey" and "bootstopkey").
>
> OK, so the thought of protecting the shell with a password has already
> happened...But the implementation is to hard-code the password in the
> U-Boot image or to have it unencrypted in the environment
>
It depends on the purpose. Here the goal was more to prevent
unintentional interruption of the boot sequence by arbitrary line
noise, for example when the serial console port is connected to a
modem ...
> I think we can agree that there is room for improvement :)
Always, and everywhere.
> Yes, but if you don't allow setting of environment variables from the host
> OS, how can you change the settings if you need to
It depends on which interfaces you want to provide and how secure your
system must be.
If you provide some user interface which only allows to change a
welldefined set of variables (say, though some GUI, or web based),
then you can have both the "change settings" and the "be secure"
parts.
If someone has low-level access to the board he can probably always do
everything, it's just a matter of how easy it is.
> Sounds like it's not a 'completely ruled out' idea...
Not exactly ruled out. It's more a question of how much effort versus
how much benefit.
Best regards,
Wolfgang Denk
--
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
The day-to-day travails of the IBM programmer are so amusing to most
of us who are fortunate enough never to have been one - like watching
Charlie Chaplin trying to cook a shoe.
prev parent reply other threads:[~2012-02-10 13:27 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-10 5:16 [U-Boot] Password protection of U-Boot command line Graeme Russ
2012-02-10 11:38 ` Wolfgang Denk
2012-02-10 11:56 ` Graeme Russ
2012-02-10 12:30 ` Marek Vasut
2012-02-10 13:31 ` Wolfgang Denk
2012-02-10 14:12 ` Frans Meulenbroeks
2012-02-10 14:27 ` Wolfgang Denk
2012-02-10 21:14 ` Frans Meulenbroeks
2012-02-11 0:44 ` Wolfgang Denk
2012-02-10 20:29 ` Mike Frysinger
2012-02-10 20:37 ` Mike Frysinger
2012-02-11 4:17 ` Graeme Russ
2012-02-11 9:00 ` Frans Meulenbroeks
2012-02-11 20:14 ` Wolfgang Denk
2012-02-12 10:03 ` Graeme Russ
2012-02-11 20:09 ` Wolfgang Denk
2012-02-12 9:33 ` Graeme Russ
2012-02-12 17:52 ` Mike Frysinger
2012-02-12 19:17 ` Wolfgang Denk
2012-02-12 22:31 ` Graeme Russ
2012-02-13 7:31 ` Wolfgang Denk
2012-02-13 11:50 ` Graeme Russ
2012-02-13 14:10 ` Wolfgang Denk
2012-02-10 13:27 ` Wolfgang Denk [this message]
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=20120210132738.AF0C714BC602@gemini.denx.de \
--to=wd@denx.de \
--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