* [U-Boot] Disable command at runtime
@ 2016-07-28 11:40 kubiznak.petr
2016-07-29 13:31 ` Tom Rini
2016-08-01 19:59 ` Wolfgang Denk
0 siblings, 2 replies; 13+ messages in thread
From: kubiznak.petr @ 2016-07-28 11:40 UTC (permalink / raw)
To: u-boot
Hello,
I wonder whether it is possible to dynamically enable/disable a command.
Since u-boot does not provide any secure authentication method, it is
dangerous to keep some commands available to a potential hacker. E.g.
the "fuse" command. On the other hand, I need these commands during the
manufacturing process. So my idea is to enable/disable the commands
dynamically based on some obscure logic. Is there a way to do it without
need to deeply hack the code?
Thanks,
Petr
--
View this message in context: http://u-boot.10912.n7.nabble.com/Disable-command-at-runtime-tp262632.html
Sent from the U-Boot mailing list archive at Nabble.com.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] Disable command at runtime
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-08-09 18:20 ` Simon Glass
2016-08-01 19:59 ` Wolfgang Denk
1 sibling, 2 replies; 13+ messages in thread
From: Tom Rini @ 2016-07-29 13:31 UTC (permalink / raw)
To: u-boot
On Thu, Jul 28, 2016 at 04:40:29AM -0700, kubiznak.petr wrote:
> Hello,
>
> I wonder whether it is possible to dynamically enable/disable a command.
> Since u-boot does not provide any secure authentication method, it is
> dangerous to keep some commands available to a potential hacker. E.g.
> the "fuse" command. On the other hand, I need these commands during the
> manufacturing process. So my idea is to enable/disable the commands
> dynamically based on some obscure logic. Is there a way to do it without
> need to deeply hack the code?
Well, there's a few ways to do this. The first way would simply be to
install a different build of U-Boot onto the board than the one used
during flashing as part of the manufacturing process.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160729/5fe0dbdb/attachment.sig>
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] Disable command at runtime
2016-07-29 13:31 ` Tom Rini
@ 2016-07-29 14:37 ` Petr Kubizňák
2016-07-29 14:59 ` Tom Rini
2016-08-09 18:20 ` Simon Glass
1 sibling, 1 reply; 13+ messages in thread
From: Petr Kubizňák @ 2016-07-29 14:37 UTC (permalink / raw)
To: u-boot
Hi Tom, thanks for your reply.
Such way is of course possible, but you surely know I'm rather
interested in more clever solutions. Besides the understandable fact
that I don't want to maintain two u-boot variants and flash it twice, I
also believe it can be useful to lock "almost everything" and unlock it
once I need, e.g. in case of some troubles.
So any suggestions which would really answer my question, please?
On 07/29/2016 03:31 PM, Tom Rini wrote:
> On Thu, Jul 28, 2016 at 04:40:29AM -0700, kubiznak.petr wrote:
>
>> Hello,
>>
>> I wonder whether it is possible to dynamically enable/disable a command.
>> Since u-boot does not provide any secure authentication method, it is
>> dangerous to keep some commands available to a potential hacker. E.g.
>> the "fuse" command. On the other hand, I need these commands during the
>> manufacturing process. So my idea is to enable/disable the commands
>> dynamically based on some obscure logic. Is there a way to do it without
>> need to deeply hack the code?
> Well, there's a few ways to do this. The first way would simply be to
> install a different build of U-Boot onto the board than the one used
> during flashing as part of the manufacturing process.
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] Disable command at runtime
2016-07-29 14:37 ` Petr Kubizňák
@ 2016-07-29 14:59 ` Tom Rini
2016-07-29 15:57 ` Petr Kubizňák
0 siblings, 1 reply; 13+ messages in thread
From: Tom Rini @ 2016-07-29 14:59 UTC (permalink / raw)
To: u-boot
On Fri, Jul 29, 2016 at 04:37:31PM +0200, Petr Kubiz??k wrote:
> Hi Tom, thanks for your reply.
>
> Such way is of course possible, but you surely know I'm rather
> interested in more clever solutions. Besides the understandable fact
> that I don't want to maintain two u-boot variants and flash it
> twice, I also believe it can be useful to lock "almost everything"
> and unlock it once I need, e.g. in case of some troubles.
>
> So any suggestions which would really answer my question, please?
It wouldn't be two variants, but two defconfigs. But, no, we do support
locking things down such that we only boot verified images. We don't
have any sort of lock/unlock or disable/enable of certain commands at
the prompt. You would be better served by having an emergency
self-contained kernel + ramdisk to deal with troubles rather than being
in U-Boot, most likely.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160729/c88e2639/attachment.sig>
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] Disable command at runtime
2016-07-29 14:59 ` Tom Rini
@ 2016-07-29 15:57 ` Petr Kubizňák
2016-08-01 20:05 ` Wolfgang Denk
2016-08-01 20:38 ` Ladislav Michl
0 siblings, 2 replies; 13+ messages in thread
From: Petr Kubizňák @ 2016-07-29 15:57 UTC (permalink / raw)
To: u-boot
Ok, I get it, then I'll have to deal with two defconfigs and reflashing
for now.
Anyway, at least a user feedback / feature request... I believe it would
be useful for many users to have a manufacturing mode, which they would
escape permanently by e.g. executing some command. In normal mode, some
commands would be disabled. Logic would be similar to
CONFIG_OVERWRITE_ETHADDR_ONCE.
On 07/29/2016 04:59 PM, Tom Rini wrote:
> On Fri, Jul 29, 2016 at 04:37:31PM +0200, Petr Kubiz??k wrote:
>
>> Hi Tom, thanks for your reply.
>>
>> Such way is of course possible, but you surely know I'm rather
>> interested in more clever solutions. Besides the understandable fact
>> that I don't want to maintain two u-boot variants and flash it
>> twice, I also believe it can be useful to lock "almost everything"
>> and unlock it once I need, e.g. in case of some troubles.
>>
>> So any suggestions which would really answer my question, please?
> It wouldn't be two variants, but two defconfigs. But, no, we do support
> locking things down such that we only boot verified images. We don't
> have any sort of lock/unlock or disable/enable of certain commands at
> the prompt. You would be better served by having an emergency
> self-contained kernel + ramdisk to deal with troubles rather than being
> in U-Boot, most likely.
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] Disable command at runtime
2016-07-28 11:40 [U-Boot] Disable command at runtime kubiznak.petr
2016-07-29 13:31 ` Tom Rini
@ 2016-08-01 19:59 ` Wolfgang Denk
1 sibling, 0 replies; 13+ messages in thread
From: Wolfgang Denk @ 2016-08-01 19:59 UTC (permalink / raw)
To: u-boot
Dear Petr,
In message <1f085e1d-378c-5f29-2f35-988b8d110da8@elnico.cz> you wrote:
>
> I wonder whether it is possible to dynamically enable/disable a command.
> Since u-boot does not provide any secure authentication method, it is
> dangerous to keep some commands available to a potential hacker. E.g.
If some evil guy has access to the U-Boot command line interface you
are pawned anyway.
> the "fuse" command. On the other hand, I need these commands during the
> manufacturing process. So my idea is to enable/disable the commands
> dynamically based on some obscure logic. Is there a way to do it without
> need to deeply hack the code?
You have to modify the code to implement such a thing; but it should
not require any "deep hacking". But then, I doubt it's useful. If
you let an attacker run _any_ commands on your system you are already
doomed. If it's in U-Boot, you lost.
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
Of course there's no reason for it, it's just our policy.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] Disable command at runtime
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-01 20:38 ` Ladislav Michl
1 sibling, 1 reply; 13+ messages in thread
From: Wolfgang Denk @ 2016-08-01 20:05 UTC (permalink / raw)
To: u-boot
Dear Petr,
In message <9c257c71-97b6-a83e-3d9d-e3a8459fc080@elnico.cz> you wrote:
>
> Anyway, at least a user feedback / feature request... I believe it would
> be useful for many users to have a manufacturing mode, which they would
> escape permanently by e.g. executing some command. In normal mode, some
> commands would be disabled. Logic would be similar to
> CONFIG_OVERWRITE_ETHADDR_ONCE.
How could that ever be "safe" - in the sense of protecting against an
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?
U-Boot is a boot loader, not a high security environment. If you
grand somebody access to the U-Boot command line interface, he owns
the system. If not directly, so by just pulling a few simple tricks.
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
If it went on at this rate, in several billion years he'd be rich
beyond his wildest dreams! - Terry Pratchett, _Soul Music_
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] Disable command at runtime
2016-07-29 15:57 ` Petr Kubizňák
2016-08-01 20:05 ` Wolfgang Denk
@ 2016-08-01 20:38 ` Ladislav Michl
2016-08-02 7:11 ` Petr Kubizňák
1 sibling, 1 reply; 13+ messages in thread
From: Ladislav Michl @ 2016-08-01 20:38 UTC (permalink / raw)
To: u-boot
On Fri, Jul 29, 2016 at 05:57:58PM +0200, Petr Kubiz???k wrote:
> Ok, I get it, then I'll have to deal with two defconfigs and reflashing for
> now.
>
> Anyway, at least a user feedback / feature request... I believe it would be
> useful for many users to have a manufacturing mode, which they would escape
> permanently by e.g. executing some command. In normal mode, some commands
> would be disabled. Logic would be similar to CONFIG_OVERWRITE_ETHADDR_ONCE.
You can still download U-Boot standalone application implementing whatever
you need to do in production, so in "normal mode" your manufacturing secrets
are not even part of your product.
Best regards,
ladis
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] Disable command at runtime
2016-08-01 20:05 ` Wolfgang Denk
@ 2016-08-02 6:57 ` Petr Kubizňák
2016-08-03 12:53 ` Wolfgang Denk
0 siblings, 1 reply; 13+ messages in thread
From: Petr Kubizňák @ 2016-08-02 6:57 UTC (permalink / raw)
To: u-boot
Dear Wolfgang,
On 08/01/2016 10:05 PM, Wolfgang Denk wrote:
> How could that ever be "safe" - in the sense of protecting against an
> 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.
> U-Boot is a boot loader, not a high security environment. If you
> grand somebody access to the U-Boot command line interface, he owns
> the system. If not directly, so by just pulling a few simple tricks.
You are absolutely right, whoever has access to U-Boot, can easily
destroy the system. The main problem is perhaps in my understanding of
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"?
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?
Best Regards,
Petr
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] Disable command at runtime
2016-08-01 20:38 ` Ladislav Michl
@ 2016-08-02 7:11 ` Petr Kubizňák
0 siblings, 0 replies; 13+ messages in thread
From: Petr Kubizňák @ 2016-08-02 7:11 UTC (permalink / raw)
To: u-boot
Dear ladis,
Thanks for your comment, I didn't really know about the standalone
applications mechanism, it might surely be useful.
Best Regards,
Petr
On 08/01/2016 10:38 PM, Ladislav Michl wrote:
> You can still download U-Boot standalone application implementing whatever
> you need to do in production, so in "normal mode" your manufacturing secrets
> are not even part of your product.
>
> Best regards,
> ladis
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] Disable command at runtime
2016-08-02 6:57 ` Petr Kubizňák
@ 2016-08-03 12:53 ` Wolfgang Denk
0 siblings, 0 replies; 13+ messages in thread
From: Wolfgang Denk @ 2016-08-03 12:53 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] Disable command at runtime
2016-07-29 13:31 ` Tom Rini
2016-07-29 14:37 ` Petr Kubizňák
@ 2016-08-09 18:20 ` Simon Glass
2016-08-10 5:54 ` Petr Kubizňák
1 sibling, 1 reply; 13+ messages in thread
From: Simon Glass @ 2016-08-09 18:20 UTC (permalink / raw)
To: u-boot
Hi,
On 29 July 2016 at 07:31, Tom Rini <trini@konsulko.com> wrote:
> On Thu, Jul 28, 2016 at 04:40:29AM -0700, kubiznak.petr wrote:
>
>> Hello,
>>
>> I wonder whether it is possible to dynamically enable/disable a command.
>> Since u-boot does not provide any secure authentication method, it is
>> dangerous to keep some commands available to a potential hacker. E.g.
>> the "fuse" command. On the other hand, I need these commands during the
>> manufacturing process. So my idea is to enable/disable the commands
>> dynamically based on some obscure logic. Is there a way to do it without
>> need to deeply hack the code?
>
> Well, there's a few ways to do this. The first way would simply be to
> install a different build of U-Boot onto the board than the one used
> during flashing as part of the manufacturing process.
Also see cli_process_fdt() which allows you to lock out commands using
a device-tree setting. This avoids changing the U-Boot binary - it is
easy enough to update the device tree using fdtput. This is how Chrome
OS did it.
Regards,
Simon
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] Disable command at runtime
2016-08-09 18:20 ` Simon Glass
@ 2016-08-10 5:54 ` Petr Kubizňák
0 siblings, 0 replies; 13+ messages in thread
From: Petr Kubizňák @ 2016-08-10 5:54 UTC (permalink / raw)
To: u-boot
Hi Simon,
> Also see cli_process_fdt() which allows you to lock out commands using
> a device-tree setting. This avoids changing the U-Boot binary - it is
> easy enough to update the device tree using fdtput. This is how Chrome
> OS did it.
Hmm, interesting approach. Thanks for your suggestion.
Petr
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2016-08-10 5:54 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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
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.