[U-Boot] Interrupt autoboot by GPIO

[U-Boot] Interrupt autoboot by GPIO

[Florian Meier]

Hi,
is there a possibility to interrupt autoboot when a GPIO pin has a
certain value? I know there is CONFIG_AUTOBOOT_DELAY_STR and that should
suffice in most cases when there is another peripheral connected to the
UART, but think about the following setup I have:

A processor (in my case a AR9331) has a single UART that is used as
U-Boot console. The same UART is connected to a radio transceiver.
Therefore, an attacker MIGHT send the CONFIG_AUTOBOOT_DELAY_STR to the
radio transceiver at the right time to insert malicious code.

I know, there are other possibilities to handle this (e.g. by ensuring
that the radio transceiver is only activated when the processor is
booted), but I think having a dedicated "interrupt autoboot"-button
would be an elegant solution.

What do you think?

Greetings,
Florian

[U-Boot] Interrupt autoboot by GPIO

[Wolfgang Denk]

Dear Florian,

In message <534D798A.9050303@koalo.de> you wrote:
>
> is there a possibility to interrupt autoboot when a GPIO pin has a
> certain value? I know there is CONFIG_AUTOBOOT_DELAY_STR and that should
> suffice in most cases when there is another peripheral connected to the
> UART, but think about the following setup I have:
> 
> A processor (in my case a AR9331) has a single UART that is used as
> U-Boot console. The same UART is connected to a radio transceiver.
> Therefore, an attacker MIGHT send the CONFIG_AUTOBOOT_DELAY_STR to the
> radio transceiver at the right time to insert malicious code.
> 
> I know, there are other possibilities to handle this (e.g. by ensuring
> that the radio transceiver is only activated when the processor is
> booted), but I think having a dedicated "interrupt autoboot"-button
> would be an elegant solution.

There is many ways to acchieve what you describe here, but we don;t
know enough of your environment to be able to give good
recommendations.

What I don't understand is wether you actually want to use this radio
transceiver as console interface device in U-Boot, or not.  If you
want to use it, then just do, and spend thoughts on restricting access
to legitimate users and uses.

If you want to prevent anybody entering interactive console mode this
way, then just set bootdelay to 0 - anything else would not make sense
anyway, as no user can acces the port.

There is tons of other options.  You could implement an input device
("keyboard) consisting just of a single key (corresponding to your
GPIO), so the key press will interrupt the boot and put the board in
interactive mode - your keyboard driver would have to switch the stdin
channel, obviously.

You could implement somewhere in the init code a test that checks the
state of the GPIO,and then modifies environment settings (say,
bootdelay, or even bootcnt - so you could auto-switch between bootcmd
and altbootcmd) to behave one way of the other. Actually this could
even be scripted - say in "preboot", so you don't even write a single
line of code.

There is many ways - if above ideas are not sufficient, then please
provide more details about what exactly you want to do, i. e. in which
way the console should be used.


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
Overflow on /dev/null, please empty the bit bucket.

[U-Boot] Interrupt autoboot by GPIO

[Florian Meier]

Hi Wolfgang,

On 04/16/2014 12:12 AM, Wolfgang Denk wrote:
> What I don't understand is wether you actually want to use this radio
> transceiver as console interface device in U-Boot, or not.  If you
> want to use it, then just do, and spend thoughts on restricting access
> to legitimate users and uses.

I do not want to use the radio transceiver as console interface, but
maintain the possibility to connect a serial cable to the same UART when
I messed it up.

> You could implement somewhere in the init code a test that checks the
> state of the GPIO,and then modifies environment settings (say,
> bootdelay, or even bootcnt - so you could auto-switch between bootcmd
> and altbootcmd) to behave one way of the other. Actually this could
> even be scripted - say in "preboot", so you don't even write a single
> line of code.

That is a great idea. The following line works fine:

#define CONFIG_PREBOOT "if gpio input 8; then setenv bootdelay 0; else
setenv bootdelay -1; fi"

Thank you very much!

Greetings,
Florian