| Message ID | cover.1716566960.git.jerome.forissier@linaro.org |
|---|---|
| Headers | show |
| Series | Introduce the lwIP network stack | expand |
Hello Jerome, On Fri, May 24, 2024 at 06:19:54PM +0200, Jerome Forissier wrote: > - Make the support of HTTPS in the wget command easier. Javier T. (CC'd) > has some additional lwIP and Mbed TLS patches to do so. With that it > becomes possible to fetch and launch a distro installer such as Debian > etc. directly from the U-Boot shell. Why this is enabling this use case? Or it is just that currently, without TLS, is not supposed to be something you should do? I am a little bit confused reading this sentence, since to me this is already possible using tftp. Francesco
Hi Francesco, On 5/27/24 11:23, Francesco Dolcini wrote: > Hello Jerome, > > On Fri, May 24, 2024 at 06:19:54PM +0200, Jerome Forissier wrote: >> - Make the support of HTTPS in the wget command easier. Javier T. (CC'd) >> has some additional lwIP and Mbed TLS patches to do so. With that it >> becomes possible to fetch and launch a distro installer such as Debian >> etc. directly from the U-Boot shell. > > Why this is enabling this use case? Or it is just that currently, > without TLS, is not supposed to be something you should do? > I am a little bit confused reading this sentence, since to me this is > already possible using tftp. You're correct. The point I am making is about using a secure (authenticated) connection, and I should have clarified that. While using HTTPS might not be critical on a local network, things are different when downloading from the internet (think man-in-the-middle attacks). Also, many web sites are switching off HTTP in favor of HTTPS so it could be that your favorite distro becomes unavailable without it. Thanks,
On Mon, May 27, 2024 at 11:36:26AM +0200, Jerome Forissier wrote: > You're correct. The point I am making is about using a secure > (authenticated) connection, and I should have clarified that. While using > HTTPS might not be critical on a local network, things are different when > downloading from the internet (think man-in-the-middle attacks). (Sorry if this sounds like nitpkicking, but I am genuinely curious) How is it supposed to work? You need not only https but also verify the presented certificate chain, and for that you need up-to-date root certificates (e.g. the bundle available from mozilla). This sounds a bit outside the scope of u-boot to me (or you should avoid the man-in-the-middle argument, which leaves the still valid "sites stop offering plain http" argument). If you really worry about man-in-the-middle you need to download via https in an environment that does certificate validation, and then even better verify the hash of the downloaded image. After that you can offer the image locally - via http, https or tftp - for installations. Martin
On 5/27/24 11:45, Martin Husemann wrote: > On Mon, May 27, 2024 at 11:36:26AM +0200, Jerome Forissier wrote: >> You're correct. The point I am making is about using a secure >> (authenticated) connection, and I should have clarified that. While using >> HTTPS might not be critical on a local network, things are different when >> downloading from the internet (think man-in-the-middle attacks). > > (Sorry if this sounds like nitpkicking, but I am genuinely curious) No worries. Well-defined use cases are certainly essential to proper implementations. > How is it supposed to work? > > You need not only https but also verify the presented certificate chain, > and for that you need up-to-date root certificates (e.g. the bundle > available from mozilla). Yes. I will let Javier comment further since he's more directly concerned with that part. > This sounds a bit outside the scope of u-boot to me Maybe, maybe not. I would argue it is a matter of deployment policy. For example assume the device is an IP camera or some other IoT thing that comes with the bare minimum to boot and fetch its OS on first power up. No guarantee about what is on the local network -- just plain internet access. https would be quite helpful in such a case. > (or you should > avoid the man-in-the-middle argument, which leaves the still valid > "sites stop offering plain http" argument). As long as there is at least one valid argument then I'm fine :) > If you really worry about man-in-the-middle you need to download via > https in an environment that does certificate validation, and then > even better verify the hash of the downloaded image. After that you > can offer the image locally - via http, https or tftp - for installations. That certainly would work but again, isn't it a decision to be made by the device manufacturer or more generally the one who builds u-boot for the device?
On Mon, May 27, 2024 at 02:45:01PM +0200, Jerome Forissier wrote: > That certainly would work but again, isn't it a decision to be made > by the device manufacturer or more generally the one who builds u-boot > for the device? Very true, and if you get the verification part working, your full solution is better! Martin
On Fri, May 24, 2024 at 06:19:54PM +0200, Jerome Forissier wrote: > This is a rework of a patch series by Maxim Uvarov: "net/lwip: add lwip > library for the network stack" [1]. The goal is to introduce the lwIP TCP/IP > stack [2] [3] as an alternative to the current implementation in net/, > selectable with Kconfig, and ultimately keep only lwIP if possible. Some > reasons for doing so are: > - Make the support of HTTPS in the wget command easier. Javier T. (CC'd) > has some additional lwIP and Mbed TLS patches to do so. With that it > becomes possible to fetch and launch a distro installer such as Debian > etc. directly from the U-Boot shell. > - Possibly benefit from additional features implemented in lwIP > - Less code to maintain in U-Boot > > The first patch introduces a new Kconfig symbol: NET_LWIP, which selects > the lwIP implementation instead of the current one (NET). Contrary to the > approach chosen by Maxim in [1], NET_LWIP and NET cannot be enabled > simultaneously. The rationale is we want to start from a clean state and > not pull potentially duplicated functionality from both stacks. Note > however that a few files are still built in net/, they are the ones > related to ethernet device management and the ethernet bootflow. > > The second patch imports the lwIP code as a Git subtree under > lib/lwip/lwip. Some glue code is added under lib/lwip/u-boot. For next time, please just make it a pre-req to run the git subtree command (and note it in the cover letter). In more specific feedback, I tried this on a Pi 3, and: U-Boot> tftpboot 200000 EFI/arm64/helloworld.efi TFTP from server 192.168.1.10; our IP address is 192.168.1.100 Filename 'EFI/arm64/helloworld.efi'. Load address: 0x200000 Loading: .... FAILED test/py/tests/test_efi_loader.py::test_efi_helloworld_net - u_boot_spawn.Timeout So some amount of networking is working (that's a reasonable dhcp response it got), but tftp'ing a file fails.
Hi all On Mon, 27 May 2024 at 15:47, Martin Husemann <martin@netbsd.org> wrote: > > On Mon, May 27, 2024 at 02:45:01PM +0200, Jerome Forissier wrote: > > That certainly would work but again, isn't it a decision to be made > > by the device manufacturer or more generally the one who builds u-boot > > for the device? > > Very true, and if you get the verification part working, your full solution > is better! Just to chime in a bit on the why. HTTPs is one of the options we can easily plug in with LWIP & mbedTLS. But apart from that, getting a richer TCP/IP stack that has been used for years in RTOSes is a win on its own. We can now easily add multiple net-based applications without having to implement the underlying TCP/IP stack. LWIP is a very slight increase in size (~1%) and the advantages are well worth it. Cheers /Ilias > > Martin
> On Fri, May 24, 2024 at 06:19:54PM +0200, Jerome Forissier wrote: > > - Make the support of HTTPS in the wget command easier. Javier T. (CC'd) > > has some additional lwIP and Mbed TLS patches to do so. With that it > > becomes possible to fetch and launch a distro installer such as Debian > > etc. directly from the U-Boot shell. > > Why this is enabling this use case? Or it is just that currently, > without TLS, is not supposed to be something you should do? > I am a little bit confused reading this sentence, since to me this is > already possible using tftp. A lot of companies don't want to run tftp any more when http(s) is more straight forward, especially when used outside of the data centre, it can be cached/proxied etc and has a bunch of other benefits before you even get to things like security and auth. Also a lot of FW vendors are starting to drop PXE/TFTP support in standards due to various things like standards requirements from governments. Peter
On 5/27/24 17:34, Tom Rini wrote: > On Fri, May 24, 2024 at 06:19:54PM +0200, Jerome Forissier wrote: > >> This is a rework of a patch series by Maxim Uvarov: "net/lwip: add lwip >> library for the network stack" [1]. The goal is to introduce the lwIP TCP/IP >> stack [2] [3] as an alternative to the current implementation in net/, >> selectable with Kconfig, and ultimately keep only lwIP if possible. Some >> reasons for doing so are: >> - Make the support of HTTPS in the wget command easier. Javier T. (CC'd) >> has some additional lwIP and Mbed TLS patches to do so. With that it >> becomes possible to fetch and launch a distro installer such as Debian >> etc. directly from the U-Boot shell. >> - Possibly benefit from additional features implemented in lwIP >> - Less code to maintain in U-Boot >> >> The first patch introduces a new Kconfig symbol: NET_LWIP, which selects >> the lwIP implementation instead of the current one (NET). Contrary to the >> approach chosen by Maxim in [1], NET_LWIP and NET cannot be enabled >> simultaneously. The rationale is we want to start from a clean state and >> not pull potentially duplicated functionality from both stacks. Note >> however that a few files are still built in net/, they are the ones >> related to ethernet device management and the ethernet bootflow. >> >> The second patch imports the lwIP code as a Git subtree under >> lib/lwip/lwip. Some glue code is added under lib/lwip/u-boot. > > For next time, please just make it a pre-req to run the git subtree > command (and note it in the cover letter). > > In more specific feedback, I tried this on a Pi 3, and: > U-Boot> tftpboot 200000 EFI/arm64/helloworld.efi > TFTP from server 192.168.1.10; our IP address is 192.168.1.100 > Filename 'EFI/arm64/helloworld.efi'. > Load address: 0x200000 > Loading: > .... > FAILED test/py/tests/test_efi_loader.py::test_efi_helloworld_net - u_boot_spawn.Timeout > > So some amount of networking is working (that's a reasonable dhcp > response it got), but tftp'ing a file fails. Thanks for testing! This fails because I changed the command output. The legacy command prints "Bytes transferred =" while the newer one prints "%lu bytes transferred" plus throughput information. I will use the older message in v3 because several tests as well as documentation would need updating. We'll do that later if desired. Thanks,
On Thu, Jun 06, 2024 at 11:15:54AM +0200, Jerome Forissier wrote: > > > On 5/27/24 17:34, Tom Rini wrote: > > On Fri, May 24, 2024 at 06:19:54PM +0200, Jerome Forissier wrote: > > > >> This is a rework of a patch series by Maxim Uvarov: "net/lwip: add lwip > >> library for the network stack" [1]. The goal is to introduce the lwIP TCP/IP > >> stack [2] [3] as an alternative to the current implementation in net/, > >> selectable with Kconfig, and ultimately keep only lwIP if possible. Some > >> reasons for doing so are: > >> - Make the support of HTTPS in the wget command easier. Javier T. (CC'd) > >> has some additional lwIP and Mbed TLS patches to do so. With that it > >> becomes possible to fetch and launch a distro installer such as Debian > >> etc. directly from the U-Boot shell. > >> - Possibly benefit from additional features implemented in lwIP > >> - Less code to maintain in U-Boot > >> > >> The first patch introduces a new Kconfig symbol: NET_LWIP, which selects > >> the lwIP implementation instead of the current one (NET). Contrary to the > >> approach chosen by Maxim in [1], NET_LWIP and NET cannot be enabled > >> simultaneously. The rationale is we want to start from a clean state and > >> not pull potentially duplicated functionality from both stacks. Note > >> however that a few files are still built in net/, they are the ones > >> related to ethernet device management and the ethernet bootflow. > >> > >> The second patch imports the lwIP code as a Git subtree under > >> lib/lwip/lwip. Some glue code is added under lib/lwip/u-boot. > > > > For next time, please just make it a pre-req to run the git subtree > > command (and note it in the cover letter). > > > > In more specific feedback, I tried this on a Pi 3, and: > > U-Boot> tftpboot 200000 EFI/arm64/helloworld.efi > > TFTP from server 192.168.1.10; our IP address is 192.168.1.100 > > Filename 'EFI/arm64/helloworld.efi'. > > Load address: 0x200000 > > Loading: > > .... > > FAILED test/py/tests/test_efi_loader.py::test_efi_helloworld_net - u_boot_spawn.Timeout > > > > So some amount of networking is working (that's a reasonable dhcp > > response it got), but tftp'ing a file fails. > > Thanks for testing! This fails because I changed the command output. The > legacy command prints "Bytes transferred =" while the newer one prints > "%lu bytes transferred" plus throughput information. I will use the older > message in v3 because several tests as well as documentation would need > updating. We'll do that later if desired. Thanks. And yeah, I would like to keep the output unchanged as much as is feasible, it's in many ways a form of ABI.