Announcement

Collapse
No announcement yet.

U-Boot Finally Lands HTTP & TCP Support For Downloading Images

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by TheMightyBuzzard View Post
    What absolute nimrod sat down and thought to themselves "You know what would be an awesome idea? Having data we have no control over in the boot process!"?
    Definitely, it has an use case: for a developer booting a kernel from the net speed up the developing process. uboot is used in small system, and it is common to build the kernel in another computer. The deploy is faster if done via network, otherwise you need to used a micro-sd....

    Another use case is for diskless system. Obviously this would requires a protected environment.

    Finally I have to point out that wget (and the TCP protocol) are addition to an already existing network stack; in fact event previously it was possible to download a kernel using tftp and udp.

    Comment


    • #12
      Originally posted by sinepgib View Post

      It's 2022 and you can sign binaries.
      You know what happens when you ask an artist to sign the PNGs they make for you? You get their name in the EXIF or even on the picture.

      You know what happens when you offer to do it yourself? Best case is an error message about the file not being signed after you've sent the build live, because you forgot to sign a PNG that you have no idea about the integrity of. Worst case scenario, you've also opened the door to having all kinds of fun trying to troubleshoot the rootkit you enabled nine months ago but had no clue about the existence of until today though.

      You know what happens when you automate its signing as part of the build process? Same as when you offer to sign it yourself except the worst case scenario is now the best case scenario.

      This is a very foolish idea for any use case except a single developer/user using an image from a protected LAN source that they also control.

      Comment


      • #13
        Originally posted by TheMightyBuzzard View Post
        This is a very foolish idea for any use case except a single developer/user using an image from a protected LAN source that they also control.
        I don´t think you understand how a trusted boot process or signing of images / verification of the signature works.

        Usecase for this 98% of the time: During development
        - Your Chip is probably "unlocked" / no public key is fused
        - You are connected via serial console and actively instruct u-boot to load a kernel image / device tree / fit-image from the HTTP adress you specify
        - You have a script in U-Boot which loads the image from your development server / machine

        During production release, your chip will be "fused", will only boot into a trusted / signed u-boot and u-boot will only boot kernel images signed by your key. Furthermore you will probably not deliver a boot script which tries to load any images over http.
        Last edited by Spacefish; 29 November 2022, 06:03 PM.

        Comment


        • #14
          Originally posted by OneTimeShot View Post
          All of these bootloaders grow bigger and bigger until they reinvent the Unix kernel…
          Nah, u-boot is rarely used as the first-stage bootloader, most SOCs have an embeeded ROM with the "real" first-stage bootloader, which configures some registers to talk to the often external storage and load / verify u-boot from the storage.
          There are even more complicated designs, where there is a boot-rom, which loads a "fist stage bootloader" from an external storage chip, which then configures a lot of registers / peripherals / timings in the chip, brings up some power domains and then loads u-boot into memmory and sets the instruction pointer to the u-boot image start.

          From the view of the Hardware, u-boot is application software running on the CPU the same as linux. The "real" bootloader is the boot-rom

          Comment


          • #15
            Originally posted by Spacefish View Post

            I don´t think you understand how a trusted boot process or signing of images / verification of the signature works.

            Usecase for this 98% of the time: During development
            - Your Chip is probably "unlocked" / no public key is fused
            - You are connected via serial console and actively instruct u-boot to load a kernel image / device tree / fit-image from the HTTP adress you specify
            - You have a script in U-Boot which loads the image from your development server / machine

            During production release, your chip will be "fused", will only boot into a trusted / signed u-boot and u-boot will only boot kernel images signed by your key. Furthermore you will probably not deliver a boot script which tries to load any images over http.
            You're correct in that I wasn't aware at what point in the release cycle the wget would be happening. It negates exactly none of my above points though. In the best possible case it's going to be used through sheer laziness from an impeccably trusted source and could easily be replaced by syncing a git tree of assets before building. Unfortunately over 90% of the developers I've met would happily use it to pull something across the Internet that comes from a server they have nothing to do with, so the best case is going to be the least common rather than the most.

            Comment


            • #16
              Originally posted by rene View Post
              I wonder why on this site everything is "finally". Why does the author not get into software development, it sounds like they would have ample,ented everything finally much much earlier, ..! A 10x engineer?
              It's answered in the actual article:

              This TCP/HTTP and wget support for U-Boot has been in the works via patches now for more than a half-decade.

              Comment


              • #17
                Originally posted by sinepgib View Post

                It's 2022 and you can sign binaries.
                And the StuxNet infection is old proof that you can't trusted signed binaries...and that isn't the only case IIRC

                Comment


                • #18
                  Originally posted by TheMightyBuzzard View Post
                  What absolute nimrod sat down and thought to themselves "You know what would be an awesome idea? Having data we have no control over in the boot process!"?
                  Any pointers on this usage of "Nimrod?"
                  Apart from a serious arse kicker from the old testament who is less reliably held responsible for the Tower of Babel fiasco I don't see the connection.
                  Coincidentally the Enigma variation of Elgar titled Nimrod was just played on the local FM radio station.

                  Comment


                  • #19
                    Why all the hate? If you don't want tcp just don't compile it in. It's not rocket science.
                    Using wget sure beats swapping a sd every boot.

                    Comment


                    • #20
                      I really dont understand the hate, I develop board support and drivers for U-boot and wget support is a huge time saver,
                      I can just spin up a Python HTTP server to serve the file and that's it.
                      For everybody that doesn't want to use it, just dont compile it in like everything else.

                      Comment

                      Working...
                      X