From: Wolfgang Denk <wd@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] Disable command at runtime
Date: Wed, 03 Aug 2016 14:53:03 +0200 [thread overview]
Message-ID: <20160803125303.1738A100434@atlas.denx.de> (raw)
In-Reply-To: <201343a2-69c2-6c3e-442b-a228190a8d07@elnico.cz>
Dear Petr,
In message <201343a2-69c2-6c3e-442b-a228190a8d07@elnico.cz> you wrote:
>
> > attacker? How could you perform such a "switch" between modes? By
> > setting some bit somewhere. And it has to be in some persistent
> > storage. And the source code of your image is available to the
> > public. What should prevent an attacker from undoing your bit
> > setting and switching back to "full" mode?
> If it was to be an irreversible switch, a reliable way might be to
> effectively remove some parts of the program by overwriting them. Not
> that I ever have done that, perhaps it's not that easy as I imagine, but
> I believe it's possible.
If you are able to overwrite the code, what would an attacker prevent
from doing the same? Note that an in-memory modification (life patch)
is sufficient.
> You are absolutely right, whoever has access to U-Boot, can easily
> destroy the system. The main problem is perhaps in my understanding of
Not only destroy, He can take control.
> the concept. I'm always tempted to keep access to U-Boot "for future
> sakes", but have not found a reliable way to deny the access to the
> others. Is there a "correct approach"?
If security is an issue, then you should 1) use signed images (with
sufficient hardware support), and 2) prevent the execution of
user-defined, unchecked commands (disable the CLI).
> By the way, once I read in some conversation that bad security is no
> security, so that's why U-Boot does not implement bad security. From my
> point of view, bad security (e.g. password stored in env) is strong
> enough to keep away the amateurs who just want to play with it and don't
> really know they might destroy the system. Of course it does not secure
> the system from the really evil attackers, but what does?
As the very first step, you have to define which security level you
need. Only then you can access which risks are acceptable and which
not. In general it is a good approach to consider an open CLI
interface in U-Boot as a mighty tool for all kinds of use.
"UNIX was not designed to stop you from doing stupid things, because
that would also stop you from doing clever things." - Doug Gwyn
Same holds for U-Boot...
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
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
Never ascribe to malice that which can adequately be explained by
stupidity.
next prev parent reply other threads:[~2016-08-03 12:53 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-28 11:40 [U-Boot] Disable command at runtime kubiznak.petr
2016-07-29 13:31 ` Tom Rini
2016-07-29 14:37 ` Petr Kubizňák
2016-07-29 14:59 ` Tom Rini
2016-07-29 15:57 ` Petr Kubizňák
2016-08-01 20:05 ` Wolfgang Denk
2016-08-02 6:57 ` Petr Kubizňák
2016-08-03 12:53 ` Wolfgang Denk [this message]
2016-08-01 20:38 ` Ladislav Michl
2016-08-02 7:11 ` Petr Kubizňák
2016-08-09 18:20 ` Simon Glass
2016-08-10 5:54 ` Petr Kubizňák
2016-08-01 19:59 ` 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=20160803125303.1738A100434@atlas.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.