Raspberry Pi Bootloader Enables OS Installs With No Separate PC Required (arstechnica.com) 63
An anonymous reader quotes a report from Ars Technica: Setting up a Raspberry Pi board has always required a second computer, which is used to flash your operating system of choice to an SD card so your Pi can boot. But the Pi Foundation is working on a new version of its bootloader that could connect an OS-less Pi board directly to the Internet, allowing it to download and install the official Raspberry Pi OS to a blank SD card without requiring another computer. To test the networked booting feature, you'll need to use the Pi Imager on a separate computer to copy an updater for the bootloader over to an SD card -- Pi firmware updates are normally installed along with new OS updates rather than separately, but since this is still in testing, it requires extra steps.
Once it's installed, there are a number of conditions that have to be met for network booting to work. It only works on Pi 4 boards (and Pi 4-derived devices, like the Pi 400 computer) that have both a keyboard and an Ethernet cable connected. If you already have an SD card or USB drive with a bootable OS connected, the Pi will boot from those as it normally does so it doesn't slow down the regular boot process. And you'll be limited to the OS image selection in the official Pi imager, though this covers a wide range of popular distributions, including Ubuntu, LibreELEC, a couple of retro-gaming emulation OSes, and Homebridge. For other OSes, downloading the image on a separate PC and installing it to an SD card manually is still the best way to go. To learn more about installing the bootloader or download the Pi OS over a network, you can view the Raspberry Pi Foundation's documentation here.
Once it's installed, there are a number of conditions that have to be met for network booting to work. It only works on Pi 4 boards (and Pi 4-derived devices, like the Pi 400 computer) that have both a keyboard and an Ethernet cable connected. If you already have an SD card or USB drive with a bootable OS connected, the Pi will boot from those as it normally does so it doesn't slow down the regular boot process. And you'll be limited to the OS image selection in the official Pi imager, though this covers a wide range of popular distributions, including Ubuntu, LibreELEC, a couple of retro-gaming emulation OSes, and Homebridge. For other OSes, downloading the image on a separate PC and installing it to an SD card manually is still the best way to go. To learn more about installing the bootloader or download the Pi OS over a network, you can view the Raspberry Pi Foundation's documentation here.
Like MacOS? (Score:3)
Doesn't MacOS do this? Good idea if you have only one Pi, or no PC.
Re: (Score:3)
Only computers which support iPXE which may require manually reflashing the boot rom.
Regular PXE is more widely supported, but requires a wired network with servers set up to answer the DHCP/TFTP requests made by the device.
The Apple implementation provides a limited UI to let you connect to a wired or wireless internet connection, and then bootstrap direct from Apple servers. A user with limited knowledge and access to a basic internet connection would be able to use it.
Re: (Score:1)
DHCP & TFTP over the Interwebs? LOL
I would bet that most ISPs that provide residential service would block DHCP intended for the Interwebs because it would mess up the ISP IP allocation services for home users.
And TFTP is not based on a resilient transport protocol (TFTP uses UDP), so dropped packets can cause it to attempt retries or simply fail, depending on the design of the TFTP implementation.
So perhaps Apple uses DHCP & TFTP (I don't use any "fruit cult" products, not even on my hairs), but I
Re: (Score:2)
No, PXE uses DHCP/TFTP, Apple do no use TFTP. As far as i'm aware, it transfers the boot image over HTTPS.
It does use DHCP to connect to the initial network. I'm not sure if it's also IPv6 capable and can use SLAAC too.
Recovery partition / Minimal Netinstall LiveCD (Score:2)
The concept is different from PXE (where an admin sets-up a dedicated server that sends something special that the computer can boot into with zero user intervention).
The concept closer to mix what is done by:
- "recovery partition" on Windows Laptops
- "Minimal netinstall" LiveCD available from multiple Linux distributions (e.g.: OpenSUSE).
(Except that it is stored in flash, instead of a separate HDD partition (windows) or on a burned CD or flashed USB stick (linux). But like linux boot media, it requires y
Can this be exploited? (Score:2)
Re:Can this be exploited? (Score:5, Informative)
In theory, yes. In practice an attacker would need to a number of favourable conditions in order for this to succeed:
- There would have to be no image signing or the signing keys would need to be compromised.
- The image would would need to be downloaded over an insecure protocol, or the cryptographic elements of transmission would need to be weak (like weak TLS ciphers)
- The attacker would need to be suitably positioned within the network to intercept the traffic.
- The attacker would further need to be present at the moment of the installation. (this step could be automated though, provided the network is already compromised)
- OS installations are quite infrequent events therefore the attacker would most likely need to succeed on first attempt.
Re:Can this be exploited? (Score:5, Insightful)
One more thing to add to the list, to address the more likely scenario of an exploit being found with new code (network install):
- Turn the network install feature off when you're done installing.
Unnecessary protocols and features in computing aren't merely unnecessary; it's your attack surface.
Re: (Score:2)
No need to do that step. This will work like any process with removable media. If removable media is present the bootloader won't execute, just like when you have a bootable USB stick in your PC it'll boot that instead of your OS of choice.
You'd need physical access to use this attack surface and at that point all bets are off.
Re: (Score:3)
No need to do that step. This will work like any process with removable media. If removable media is present the bootloader won't execute, just like when you have a bootable USB stick in your PC it'll boot that instead of your OS of choice.
Yeah, or perhaps since the Pi is going "network-boot", I just find or create an exploit that bypasses the media check, or modifies the boot order (going back to your USB stick scenario) Features create complexity. Complexity usually has to be analyzed so risk can be mitigated.
If the feature is enabled, it could be exploited. If you don't need it, don't just rely on other process to check-and-bypass. Disable it.
You'd need physical access to use this attack surface and at that point all bets are off.
While I admit that my concepts above are theoretical, IF the security of the current code can
Re: (Score:2)
Yeah, or perhaps since the Pi is going "network-boot", I just find or create an exploit that bypasses the media check
Sure. All you need is access directly to the pi so you can upload a new firmware into the EEPROM at which point I wonder why would you then leave and exploit remotely when you already have console access.
This is no different than any UEFI implementation. You will need to be able to already execute code on the device likely with root credentials to get yourself in a position for this to work.
IF the security of the current code can ensure this
You could help the effort by auditing the code. The code is open source and up on the RPI github page.
It's just a boot payload (Score:2)
Yeah, or perhaps since the Pi is going "network-boot",
The Pi isn't network booting (i.e.: it's not waiting for a payload to be sent from accross the network for booting into without any user intervention, like PXE).
It's just an extra payload embed in the bootload firmware image that uboot can boot into.
It's just an extra option in the boot order, that is available at the end of the list:
- boot from SD
- boot from USB storage
- boot from PXE, if configured
- boot the embed "minimal netinstall" image, if the user choose to.
Booting into this "minimal netinstall" ima
Re: (Score:2)
I just tried this and I don't see any significant difference compared with just getting and running the regular Raspberry Pi Imager https://www.raspberrypi.com/so... [raspberrypi.com] which is the recommended "quick and easy way to install Raspberry Pi OS and other operating systems to a microSD card, ready to use with your Raspberry Pi."
It's basically just running that, sure it'll also download a basic kernel and root file-system to be able to run it but there's no particular reason to think it'll be worse than a regular u
The Computerless Computer. (Score:5, Insightful)
"To test the networked booting feature, you'll need to use the Pi Imager on a separate computer...
*looks at title again*
Wait, didn't you JUST brag...
Re: (Score:2)
Presumably this is only needed for the beta test. Eventually it will be installed in the firmware for the Pi 4, like a BIOS update.
They did this before with support for booting off USB. Very handy for using a USB SSD with better durability than an SD card.
Re: (Score:2)
Oxymoron (Score:4, Insightful)
"You need another PC to write the SD card"
Re: (Score:3)
To test it.
Presumably they'll embed their little stub OS in some kind of nonvolatile memory on the board in the future.
So yay, another unnecessary line on the BOM for the $25 computer. Um, I mean $100 computer.
Re:Oxymoron (Score:4, Informative)
RPi 4s already have a bootloader, which gets loaded from onboard storage. All that's happening here is a new bootloader has been developed that (1) fits within the constraints of whatever storage is built in while (2) adding the ability to install from the network to an empty SD card. If it needed new hardware, it wouldn't work with any existing devices. As it is, it only works with the RPi 4 because earlier devices used a different method to boot that doesn't involve a bootloader.
Re: (Score:2)
You're right, the RPi 4 already added EEPROM. It's great they're working on the higher end devices, but it would be nice if they also had a look at their low end with an eye to reducing cost. Their original mission seems to be getting ignored.
Re: (Score:3)
The hardware already includes nonvolatile memory on the board which contains a bootloader. All this is doing, is replacing that bootloader with a newer version that has additional functionality.
Worst case, a higher capacity chip would be required - but that's not going to make a huge difference to the cost especially since the price of such things decreases over time.
Re: (Score:2)
Well, the bootloader is necessary and was there from day 0, of course. You can see for yourself, it works on any Pi4 including the very first ones from 2019. Now you might say "oh, some unnecessary dev work, why are you wasting time with network boot" or as it was earlier with USB boot or generally why are they still supporting even Pi1 from 10 years ago on their latest OSes? I don't want to pay for unnecessary suppor
Re: (Score:2)
So yay, another unnecessary line on the BOM
I don't think you understand how SoCs work. Hint: This doesn't show up on a BOM.
You may have heard of this thing called "firmware" which is present in every SoC on the market. On the BCM2711 it happens to be an EEPROM.
So yay literally another unnecessary post by ceoyoyo drunk posting his ignorance.
Re: (Score:2)
Does this mean I've got a Slashdot stalker? Finally made it!
Re: (Score:2)
Not really. I just seek out ignorant posts and your name seems to be attached to them. You have a good marketing manager, though I question the choice of brand you're going for.
Re: (Score:2)
Speaking of which, you may wish to read this:
https://www.raspberrypi.com/do... [raspberrypi.com]
All pis except the 4 boot from the MicroSD flash card. The 4 is the first to have on-board non-volatile memory, which is in two EEPROM chips (one seems to be for the USB 3 controller). I was unaware that EEPROMs had *already* been added to the pi 4. They most certainly would appear on the BOM.
Application processors generally don't have integrated boot memory. IIRC none of the common ones surveyed here did: https://jaycarlson.net/e [jaycarlson.net]
Re: (Score:2)
You can buy an SD card preloaded with OS from amazon and I'm sure other places.
https://www.amazon.com/Raspber... [amazon.com]
Re: (Score:2)
Re:Oxymoron (Score:4, Insightful)
Re: (Score:2)
This is great (Score:2)
except you can't buy a pi without a 100% markup right now.
Re: (Score:2)
Re: (Score:2)
I'm also being a good consumer and stopping purchases when prices are high
Re: (Score:2)
What a bargain! (Score:2)
Damn! Where can I find a new Pi for only a 100% markup!?
Used Pis are going for 100% over MSRP.
Isn't this just PXE Boot? (Score:2)
I know that my Pi 4s have this ability, and have been meaninfg to use it to boot them off of my Synology NAS, but never got around to it.
Re: Isn't this just PXE Boot? (Score:3)
Pxe is fine if you have a tftp server and control of dhcp on your local network.
If you don't, and want to install and OS from the internet, PXE is a bit useless
Re: (Score:2)
Fix the actual bugs first (Score:3)
Re: (Score:2)
There's nothing to fix and this is not a bug. There's no matching arch option for the Raspberry Pi's boot architecture assigned by the IANA so you're going to be squatting on someone else's arch regardless of what you do, or you pick an invalid configuration which risks breaking network boot altogether.
There's a reason the Raspberry Pi sends 0x34695052 as Option97. That is what you need to match. There's no need to remotely match the MAC and hasn't been for 2 years since they worked around the issue. You ca
Re: (Score:2)
Re: (Score:2)
Because aarch64 is not a thing which exists. The closest they could get is "16" which identifies arm 64 but then has the wrong bootloader. The option code doesn't just identify the architecture of the system, it also identifies the bootloader. "0" isn't x86, "0" is x86 BIOS, most PCs will identify themselves as "7" x86 UEFI.
Whatever you do you have to squat somewhere. The question is: do you propose a solution allowing unique identification, such as using option code 97, or do you propose a solution allowin
Re: (Score:2)
Re: (Score:2)
No I mean the definition used here defines the specific implementation. The Raspberry Pi identifying itself as "0" would be no different from an x86 UEFI machine identifying itself as "0" since "0" is reserved only for classic BIOS implementations.
In the same way the Raspberry Pi doesn't fit in any of the defined numbers for identification. If it were on "16" it would at least be arm64, but it's not a uboot implementation so that's not right either. It literally does not match any of the defined numbers.
The Option97 that does the "RPI" identification might be a stable way to identify the boards, but just feels like a Microsoft approach to standardisation.
I t
Why not iPXE? (Score:4, Insightful)
It already supports a plethora of hardware, and it is surprisingly trivial to netboot and netinstall off of it. There are many pulic boot servers you can point iPXE to, and then you get a menu of a huge selection of OS you can boot or install - all over the internet.
As a plus, you can even burn iPXE to your NIC's flash (although I simply run it via grub).
Re: (Score:2)
> There are many pulic boot servers you can point iPXE to, and then you get a menu of a huge selection of OS you can boot or install - all over the internet
--Do you happen to have a link to a decent HOWTO for this?
Re: Why not iPXE? (Score:2)
You can then chain boot into e.g. netboot.xyz
iPXE was a relevation to me. It really is awesome. Highly recommended! You can even boot
No idea why this isn't way, way more popular.
For learning and debugging, I set it up in a VirtualBox running some basic Debian. You an apt-get iPXE, and then just fiddle around with
So ... (Score:2)
Modern laptops already do something like this for their firmware.
I do not approve but Rasberry hardware tends to be single-purpose computing so the opportunities for spyware may be lower.
Too late - they designed and made the hardware (Score:5, Insightful)
If the Raspberry Pi Foundation wanted to sneak code onto the Pi, they would have done it at the factory. They literally designed the Pi 4 chip.
Once you plug the hardware in to your network, you've ALREADY decided to trust the people who designed and made the hardware. You don't have to / get to make that decision when you're downloading the software from them. You're already trusting them.
Re: (Score:2)
yes netboot/PXE-based (Score:2)
so this was a "feature" being able to netboot
even UFI has it ,one of the new features in UEFI 2.5 is the use of the HTTP protocol for network booting. Previously, UEFI booted remotely, using IPv4 or IPv6, starting with DHCP, then finishing using TFTP, “PXE-based”. This new UEFI 2.5 change defines new DHCP options to specify URI-based pointers to the “Network Boot Program (NBP)”, the binary image to download and run, which can be used using HTTP instead of TFTP. DHCP Servers will need
Re: (Score:2)
if only this were relevant to the topic.
This has been possible... (Score:2)
Wrong Direction (Score:2)
Re: (Score:2)
Is it a more "insecure by design philosophy" than installing an OS downloaded from the internet and booting it locally?
Re: (Score:2)
Or for that matter than getting any OS updates from the Internet or even app updates if they run with high enough privileges.
Have we reached peak Pi? (Score:2)
However I'm wondering if we're reaching a point of decline in RPi development. In general people don't seem as interested in RPi as they were a few years back, and the 4 has been the top of the line for some time without much word on what comes next. Sure, it's available in a few different confi
Re: (Score:2)
Just see as of end of May 2021 "After launching five devices in less than a year, here's what they're doing next". : https://www.techrepublic.com/a... [techrepublic.com] . Note that they aren't counting separately the compute module (wild) variations based on RAM and onboard flash (this is the Pi with a PCI-E connector, think connecting directly 16 hard drives to a Pi).