Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Operating Systems

Raspberry Pi Bootloader Enables OS Installs With No Separate PC Required (arstechnica.com) 63

Posted by BeauHD from the simplified-installations dept.
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.
This discussion has been archived. No new comments can be posted.

Raspberry Pi Bootloader Enables OS Installs With No Separate PC Required More

Raspberry Pi Bootloader Enables OS Installs With No Separate PC Required

Comments Filter:

  • Like MacOS? (Score:3)

    by HoleShot ( 1884318 ) on Tuesday February 08, 2022 @06:24PM (#62251169)

    Doesn't MacOS do this? Good idea if you have only one Pi, or no PC.

  • To remotely install a rogue OS on a Pi? What about if you are able to intercept a Pi downloading an OS using a MiTM attack, any possibility for injecting malware?

    • Re:Can this be exploited? (Score:5, Informative)

      by devslash0 ( 4203435 ) on Tuesday February 08, 2022 @06:32PM (#62251191)

      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)

        by geekmux ( 1040042 ) on Tuesday February 08, 2022 @06:40PM (#62251219)

        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.

        • 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.

          • 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

            • 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.

            • 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

    • 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)

    by geekmux ( 1040042 ) on Tuesday February 08, 2022 @06:30PM (#62251179)

    "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)

      by AmiMoJo ( 196126 )

      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)

      by WallyL ( 4154209 )
      They meant serverless!

  • Oxymoron (Score:4, Insightful)

    by freeze128 ( 544774 ) on Tuesday February 08, 2022 @06:31PM (#62251185)
    "Raspberry Pi no longer needs another PC to install it's OS"

    "You need another PC to write the SD card"

    :-/

    • Re: (Score:3)

      by ceoyoyo ( 59147 )

      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)

        by ncc74656 ( 45571 ) * <scott@alfter.us> on Tuesday February 08, 2022 @07:23PM (#62251311) Homepage Journal

        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)

          by ceoyoyo ( 59147 )

          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)

        by Bert64 ( 520050 )

        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.

      • So yay, another unnecessary line on the BOM for the $25 computer. Um, I mean $100 computer.

        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

      • 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)

          by ceoyoyo ( 59147 )

          Does this mean I've got a Slashdot stalker? Finally made it!

          • 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)

              by ceoyoyo ( 59147 )

              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]

    • You can buy an SD card preloaded with OS from amazon and I'm sure other places.

      https://www.amazon.com/Raspber... [amazon.com]

      • Thank you. Seems like a much simpler solution!

        • Re:Oxymoron (Score:4, Insightful)

          by trparky ( 846769 ) on Tuesday February 08, 2022 @10:47PM (#62251577) Homepage
          That's assuming, of course, that what you buy from Amazon is an authentic Raspberry Pi pre-loaded SDCard. Considering Amazon's recent track record with fake products, I wouldn't put much stock in it.
          • That's a fair point. I would hope the code is signed, though, such that if the product were malicious (rather than just an equivalent knock-off), it would fail. If its a knock-off that boots and loads the correct code, you've still achieved your goal.

  • except you can't buy a pi without a 100% markup right now.

  • 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.

    • 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

      • Even if you can't put PXE boot options on your DHCP, you could run DNSMasq as a DHCP proxy and deploy the boot settings that way. DNSMasq can also run a read-only tftp server for you!

  • Fix the actual bugs first (Score:3)

    by Skinkie ( 815924 ) on Tuesday February 08, 2022 @07:34PM (#62251337) Homepage
    It is obviously nice that such functionality appears. But the current PXE identification of the RPi4 is an x86 PC, instead of aarch64. There are other attributes that prevent an ordinary identification of the board outside of the MAC address realm. Fix those things first.

    • 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)

        by Skinkie ( 815924 )
        Why isn't aarch64 correct in your opinion, but "0" (x86) is?

        • 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)

            by Skinkie ( 815924 )
            When you state "it has the wrong bootloader" do you mean it does not work like one could expect from true pxe implementations? "Most PCs" here is only the PC's that have UEFI enabled, a common use case like booting Virtrual Box is hardly possible with the EFI option enabled. Principally what they implemented has cut some corners, personally I would like to see that fixed. The Option97 that does the "RPI" identification might be a stable way to identify the boards, but just feels like a Microsoft approach to

            • 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)

    by schweini ( 607711 ) on Tuesday February 08, 2022 @08:12PM (#62251371)
    Why wouldn't they simply use the awesome iPXE?
    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)

      by Wolfrider ( 856 )

      > 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?

      • I just followed the stuff on iPXE.org
        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 .iso files of HTTP over the internet! And have menus, and ask for parameters and so on. No more fiddling around with tFTP and DHCP settings and all that.
        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 a manual boot-loader for (encrypted) FTP and automated installation of signed software.

    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.

  • All you need is a pxe host and there were some out on the internet for a while...
  • Boot over the internet is an insecure by design philosophy. Any cloud dependency is still a dependency, negating the idea of a personal computer. Why stop there, why not part out each feature of independence that makes it a personal computer--until you have a dumb terminal hooked up to someone else system?

    • Re: (Score:2)

      by dfghjk ( 711126 )

      Is it a more "insecure by design philosophy" than installing an OS downloaded from the internet and booting it locally?

      • Or for that matter than getting any OS updates from the Internet or even app updates if they run with high enough privileges.

  • I'll start this by saying I'm quite fond of the RPi; I have three of them on my home network. They are great for what they do, and for how little money (both purchase and power consumption) they need to do it.

    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

    • I hope we see more development from the RPi team, it is a really clever design. I'm just not sure that the market has enough demand to take this much further.

      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).

Slashdot Top Deals

Make sure your code does nothing gracefully.

Close