Skip to contentSkip to conversation

Interrupt autoboot by GPIO

U-Boot Florian Meier 2 participants 3 messages Apr 15, 2014 – Apr 16, 2014

lore
Share & tools
lore
#0 lore raw

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

#1 lore raw

Dear Florian,

Quoted 11 lines · In message <[email protected]> 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.

Quoted 4 lines

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

Signature · 4 lines
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.
#2 lore raw

Hi Wolfgang,

Quoted 4 lines · Wolfgang Denk

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.

Quoted 6 lines

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