From: Wolfgang Denk <wd@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] Password protection of U-Boot command line
Date: Sat, 11 Feb 2012 01:44:13 +0100 [thread overview]
Message-ID: <20120211004413.412C414BC602@gemini.denx.de> (raw)
In-Reply-To: <CACW_hTY7sv6q+Y9+ojkg2PNJ4GRt0rwKHAHzaSb2SGxYHrioRQ@mail.gmail.com>
Dear Frans,
In message <CACW_hTY7sv6q+Y9+ojkg2PNJ4GRt0rwKHAHzaSb2SGxYHrioRQ@mail.gmail.com> you wrote:
>
> > If you want security, then don;t allow access to U-Boot at all, and
> > run an OS. There you can do fancy things, including password
> > protection.
>
> The issue is mainly that we would like a service engineer to upgrade
> if for some reason the os goes into a not recoverable fault, without
> an operator accidently (or on purpose) bumping into it
This is a perfectly reasonable requirement. But it needs to be
designed in, but providing things like fall back to a previous
version, or to a recovery configuration. U-Boot supports allthis, you
just have to use it.
Passwords are not a tool that would help here.
> > Do you realize that you are already talking how to maintain this
> > "security" level in Linux? Then also implement it there! That's
> > where such stuff belongs to.
> >
> probably yes. my concern is mostly about being able to repair systems
> where something is broken and the kernel does not come up as desired
> but also does not crash and bring us back to u-boot (like what happens
> if a crc is faulty).
>
> What Mike suggests in a subsequent message of using is more or less
> secret key is probably already enough for us.
No. What you are looking for is a reliable recovery for a failed
software update or an otherwise corrupted system. That's a completely
different topic - but it's standard techology, and nothing to worry
about.
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
COBOL is for morons. -- E.W. Dijkstra
next prev parent reply other threads:[~2012-02-11 0:44 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 [this message]
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
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=20120211004413.412C414BC602@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.