[U-Boot] Disable command at runtime
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.
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.
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.
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.
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.
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@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_
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
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
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
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
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
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
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
participants (6)
-
kubiznak.petr -
Ladislav Michl -
Petr Kubizňák
-
Simon Glass -
Tom Rini -
Wolfgang Denk