Raspberry Pi 4 usb boot?

[bjtheone]

If a sociable engineer posting for the first time claimed to have created a new EEPROM image that supported USB boot and gave a link here, how many people do you think would try it out? What if some virtual trolls posted that it actually worked and did indeed support USB boot?

Sadly I don't agree with your assessment, if you are suggesting that no one would try it (is hard to figure out which way your statement should be taken). If such a person posted on the Raspberry Pi forums they would quickly be debunked. However, I still bet someone would try it before a moderator got to them. Many (most ?) people really do not have a clue about computers. They are magic black boxes that do stuff. Admittedly the bar is raised somewhat by the Pi not being a mainstream computer, but I am amazed by what people are willing to blindly run/try

There are unfortunately also lots of other venues to put up such crap and drive searches to.

[Gavinmc42]

I've already finished the most difficult part: finding a good name for the boot loader. Instead of grub, I've decided to call it slug.

Have you got a mascot logo for that yet?
It might run faster than you think,- Turboslug?
Rats, that name is taken

[NOsen]

Hey,

Anyone figured out why it wont find usbstick when it plugged into the usb3 ports but works from the usb2 ports? (boot from sd card system on usb)

[clicky]

Hey,

Anyone figured out why it wont find usbstick when it plugged into the usb3 ports but works from the usb2 ports? (boot from sd card system on usb)

Maybe you need (bigger?) delay. I've just checked - I have:

Code: Select all

 rootdelay=5

at the end of /boot/cmtline.txt

[hippy]

To make use of "hackable" EEPROM on the pi4 one would need to:
1a) hack the os remotely and gain root access.
or
1b) have local physical access

Or just convince someone to run a Python program. Or any program which does what would be needed.

A more determined miscreant would perhaps pursue getting what's needed installed via a hacked repository or dependency, sit back and wait for that to trickle down to users.

2) Have deep knowledge of VC4/6 hardware and software architecture and have knowledge of and access to all the needed tools to build their own bootloader code which is closed source and AFAIK is very peculiar architecture, I think the amount of people in the world capable of writing their own malicious vc4/6 bootloader is very small, like a dozen or two of persons.

I believe it could be more than that, though it depends on what level of maliciousness one is talking about.

It is easy enough to be a nuisance by getting one's own Boot Eeprom code written and in there, but it is harder to see how one could make it truly malicious, basically because it is only a bootloader.

I can think of some very petty things to do which could be extremely frustrating before the user reflashed a Boot Eeprom with recovery.bin to get things working properly again. There could potentially be things done which rendered a Pi unbootable after a re-boot.

In terms of something which hides in the Boot Eeprom, persists once the system is booted and running, effectively 'backdooring it' in some way; maybe it is possible but that would be well beyond my pay grade and most others.

[dickon]

'only a bootloader'! -- you get to load the kernel, any initrd, dtb, and commandline into RAM, edit them as you see fit (the dtb in particular is actually required to be altered by the bootloader, and that has the addresses of all sorts of entertaining devices embedded within it), and, if you're feeling malicious, fiddle with any or all of those as you see fit, within the constraints of whatever resources you have to play with. You can patch the running kernel, invisibly, with whatever you wish. Not happy with the exception vectors? Fine. Replace them. Not happy with the UART driver? Have fun.

You can do a lot with a bootloader, particularly with unsigned binaries. UEFI Secure Boot was designed to overcome this. Don't get me started on it, however...

[hippy]

'only a bootloader'! -- you get to load the kernel, any initrd, dtb, and commandline into RAM, edit them as you see fit ...

I was under the impression the Boot Eprom only kicks things off and there is a whole chain of things which push earlier parts of the chain out of the way as the system actually comes up.

Thus the Boot Eprom code would have relinquished control long before what it would have to do to be truly malicious could be done. I am not even sure the ARM cores would be running when the Boot Eprom code relinquishes control.

The Boot Eprom code could of course hack stuff it is loading and relinquishing control to to hack things later in the chain and all the way down but that seems a huge undertaking. And one would be up against the limited Boot Eprom capacity. It may be possible but, as I said; beyond my pay grade.

[dickon]

Doesn't really matter, TBH. The way these things tend to run, the likes of Google's Project Zero *will* find a way to exploit what you think is unexploitable. A first-stage bootloader has the ability to alter *everything* that comes after it. It's a deeply powerful position to be in.

[dickon]

TBH, the question was asked, answered ('yeah, soon'), and we've had a further 11.5 pages of rubbish since. If the mods haven't locked it by now -- and they haven't, yet -- well, personally, I consider it fair game.

It hasn't been entirely fruitless.

And for the record, I consider what I suggested above vanishingly unlikely. Possible, but won't happen.

[NOsen]

Hey,

Anyone figured out why it wont find usbstick when it plugged into the usb3 ports but works from the usb2 ports? (boot from sd card system on usb)

Maybe you need (bigger?) delay. I've just checked - I have:

Code: Select all

 rootdelay=5

at the end of /boot/cmtline.txt

Thanks I'll give it a try!

[Gavinmc42]

Do/will the USB3 ports get checked before the USB2 ones.
I supposed most would prefer to boot from USB3?

[jdb]

The question is moot - in the existing implementation on Pi3B+, all connected USB devices are enumerated and probed to get a list of mass-storage devices. The first device that has a valid bootcode.bin is used to boot from. An analogue of this will be used on Pi 4, so as to not break USB disk images that can boot on a Pi3b+ or a Pi4.

I can't think of a plausible situation in which you would have connected 2 SSDs with Pi bootloaders on and need to switch between the two.

[ejolson]

I can't think of a plausible situation in which you would have connected 2 SSDs with Pi bootloaders on and need to switch between the two.

It seems likely to me that even a single disk might have multiple Pi boot directories that one would like to choose from. After searching, a grand unified bootloader could enumerate all of them, make a menu to choose from and then timeout to a preselected default if no choice is made.

At the moment I'm having trouble with kexec for the slug boot loader. Is there any documentation how NOOBS (and similarly PINN) switches back and forth between the installer and the selected operating system image?

I've already finished the most difficult part: finding a good name for the boot loader. Instead of grub, I've decided to call it slug.

Have you got a mascot logo for that yet?

Do you think UCSC would let me borrow their mascot?

[jdb]

Then make a chainloader. USB boot is intentionally limited in scope to "find the first valid boot disk and boot from it".

[ejolson]

Then make a chainloader. USB boot is intentionally limited in scope to "find the first valid boot disk and boot from it".

I'm trying to make a chain loader. It will be called slug.

Do you have any idea how to make kexec work on the Raspberry Pi?

How does NOOBS do it?

[rpdom]

Then make a chainloader. USB boot is intentionally limited in scope to "find the first valid boot disk and boot from it".

I'm trying to make a chain loader. It will be called slug.

Do you have any idea how to make kexec work on the Raspberry Pi?

How does NOOBS do it?

NOOBS doesn't use kexec. It uses a flag in the SoC (somewhere under /sys) that specifies which partition to use for the next boot, then performs a reboot.

[ejolson]

Then make a chainloader. USB boot is intentionally limited in scope to "find the first valid boot disk and boot from it".

I'm trying to make a chain loader. It will be called slug.

Do you have any idea how to make kexec work on the Raspberry Pi?

How does NOOBS do it?

NOOBS doesn't use kexec. It uses a flag in the SoC (somewhere under /sys) that specifies which partition to use for the next boot, then performs a reboot.

That is my understanding as well. Is there any documentation? What are the details?

[trejan]

NOOBS doesn't use kexec. It uses a flag in the SoC (somewhere under /sys) that specifies which partition to use for the next boot, then performs a reboot.

That is my understanding as well. Is there any documentation? What are the details?

/sys/module/bcm270x/parameters/reboot_part is long gone and was removed with the change to preferring the upstream kernel drivers.

NOOBS now passes the partition using the reboot syscall with the magic number for LINUX_REBOOT_CMD_RESTART2 and the partition as the command. The watchdog driver picks up that value and sets the PM_RSTS register to indicate which partition to boot from.

The odd way it jams the value into the register is because PM_RSTS is meant to show the reset reason with bits for various types of software, watchdog and debugger resets but it is being (ab)used to pass the value to the firmware.

[ejolson]

NOOBS doesn't use kexec. It uses a flag in the SoC (somewhere under /sys) that specifies which partition to use for the next boot, then performs a reboot.

That is my understanding as well. Is there any documentation? What are the details?

/sys/module/bcm270x/parameters/reboot_part is long gone and was removed with the change to preferring the upstream kernel drivers.

NOOBS now passes the partition using the reboot syscall with the magic number for LINUX_REBOOT_CMD_RESTART2 and the partition as the command. The watchdog driver picks up that value and sets the PM_RSTS register to indicate which partition to boot from.

The odd way it jams the value into the register is because PM_RSTS is meant to show the reset reason with bits for various types of software, watchdog and debugger resets but it is being (ab)used to pass the value to the firmware.

These code references are very helpful. It looks like rebootp in PINN

https://github.com/procount/pinn/blob/m ... /rebootp.c

is using the same mechanism.

[trejan]

These code references are very helpful. It looks like rebootp in PINN

https://github.com/procount/pinn/blob/m ... /rebootp.c

is using the same mechanism.

Yeah. The rebootp utility is so you can manually change it from the recovery shell. The PINN boot menu uses the syscall directly like NOOBS

[rtfmoz]

If the EEPROM is writable and accessible it is hackable.

To make use of "hackable" EEPROM on the pi4 one would need to:
1a) hack the os remotely and gain root access.
or
1b) have local physical access

2) Have deep knowledge of VC4/6 hardware and software architecture and have knowledge of and access to all the needed tools to build their own bootloader code which is closed source and AFAIK is very peculiar architecture, I think the amount of people in the world capable of writing their own malicious vc4/6 bootloader is very small, like a dozen or two of persons.

Please stop spreading the FUD.

Hi, I have security concerns as well and its quite interesting that you call this FUD. I can guarantee you blackhats will be looking at how to exploit a writable boot EEPROM on Pi4. It's literally a treasure chest. Mind you the use case will be interesting as they need to reach the device to reprogram it. When they do they would probably see the Linux OS as a goldmine anyway and its raw capability to act the perfect launchpad for network forensics in preparation for a coming intrusion. Expect said tools coming to a security conference near you, if not already.

Anyway, this is off-topic. Thanks for the hard work bringing out the Pi4 and we look forward to new boot code with new features. If you have any blog posts regarding the security of the Pi4 can you point me to them, please?

[pepeEL]

Hi
Any news about boot from USB on RPI4 ?

[jamesh]

Hi
Any news about boot from USB on RPI4 ?

No, which is why we haven't announced any news.

[pepeEL]

Because i see that network boot was added....

[jamesh]

Because i see that network boot was added....

Yes, network boot has been added. Nothing to do with USB boot though, which will be announced when it's ready. Still a few months away I suspect.