From: Ahmad Fatoum <a.fatoum@pengutronix.de>
To: David Jander <david@protonic.nl>, Martin Wege <martin.l.wege@gmail.com>
Cc: Barebox List <barebox@lists.infradead.org>,
Cedric Blancher <cedric.blancher@gmail.com>,
Dan Shelton <dan.f.shelton@gmail.com>
Subject: Re: Mount NFSv4.2 filesystem in barebox?
Date: Wed, 5 Mar 2025 13:51:51 +0100 [thread overview]
Message-ID: <7b73bca5-c1a2-4260-9c8a-510887ba4be8@pengutronix.de> (raw)
In-Reply-To: <20250305123032.2b2c7768@erd003.prtnl>
Hi David,
On 05.03.25 12:30, David Jander wrote:
> On Tue, 4 Mar 2025 22:50:00 +0100
> Martin Wege <martin.l.wege@gmail.com> wrote:
>> So yes, you would have customers for NFSv4.1 support in barebox.
>
> Just wanted to chime in to amplify this a bit, since we are also using NFSv4.2
> netboot (though only TFTP in barebox for now):
>
> Your arguments are solid, and make a lot of sense. If you are going to replace
> more and more microcontroller based nodes with Linux capable SoCs, because it
> makes a lot of economical sense (hardware costs are very similar nowadays, and
> software development is 10x easier and cheaper on Linux than on a uC), you
> will end up inevitably with a lot of Linux nodes inside of a machine or
> industrial plant, where you previously had uC's. So, do you want to continue
> using 1970's tech (RS485/modbus) or 1980's tech (CAN) to communicate between all
> those nodes, or will you use Linux's native language (TCP/IP) which also
> immediately means another 10x reduction in software development costs of the
> networking part? If you choose the latter, you will also get significant HW
> cost savings basically for free if you also net-boot (via NFS and/or TFTP).
>
> In other words, why are we not already doing this?
>
> At least we are. We are starting to use Single Pair Ethernet almost everywhere
> where there were other field-busses involved traditionally. So we noticed that
> we end up with a lot of boards running Linux connected together via anything
> from 10Base-T1L to 1000Base-T1. Replace the eMMC chip on all but one of them
> with a cheap 2MiB SPI-NOR flash to load barebox and netboot from one single
> board running an NFSv4.2 (and TFTP) server serving the kernel and rootfs for
> all the others from a single eMMC, that can be updated with a single RAUC
> bundle guaranteeing consistent software and trivially easy updates on all
> nodes at once. Not to mention the benefit of trivial repairs because all
> boards are basically dumb and don't need to be flashed with software that
> matches the machine they are being replaced in, etc...
Which I think is very cool. :-)
> To be fair though, it isn't strictly needed for barebox to have NFS support
> for our use-case, since it suffices to load the kernel (and possibly an
> initramfs) via TFTP and mount the nfsroot from the kernel, but IMHO it is
> certainly valuable to have basic NFSv4.2 support in barebox. It would
> facilitate the use of just 1 protocol instead of 2.
Ack.
> I also agree that NFSv3
> support in that regard offers little value since you really don't want to base
> everything on this obsolete version with all of its limitations.
>
> But also a bit of caution to be mindful of: Cybersecurity. Of course barebox
> can be made to only boot signed fit images, but are there other potential
> attack vectors?
We have been fuzzing the security critical boot path and issues were found
and fixed. Our network stack and NFS implementation are not currently part
of that. The documentation now spells that out and explicitly advises
against using any unsigned file system at all (whether networked or not)
to contain a signed FIT image:
https://www.barebox.org/doc/latest/user/security.html#avoiding-use-of-file-systems
As we gain more confidence in the implementation (or rather import mptcp and focus
on fuzzing that), this will change, but as things stand now, it's is not advisable
to do network boot of signed images.
> What if the NFS server needs to be secured with with GSS and
> kerberos? Barebox possibly won't be able to access it unless it also supports
> that.
Yes. I think HTTP(S) support may be a better investment of time, even
if it means having to use two protocols still.
> P.S.: I am currently not subscribed to the barebox mailing list, so I don't
> know if this email will get forwarded by the list server.
The ML accepts mails from non-subscribers. Infradead is currently slow on
delivering mail, though, but I hope it will soon show up on both
lore.barebox.org/barebox and lore.kernel.org/barebox.
Cheers,
Ahmad
>
> Best regards,
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
next prev parent reply other threads:[~2025-03-05 14:03 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-11 12:56 Martin Wege
2025-02-12 14:33 ` Sascha Hauer
2025-02-21 11:54 ` Martin Wege
2025-02-28 10:57 ` Sascha Hauer
2025-03-03 8:40 ` Ahmad Fatoum
2025-03-04 21:50 ` Martin Wege
2025-03-05 11:30 ` David Jander
2025-03-05 12:51 ` Ahmad Fatoum [this message]
2025-03-05 13:55 ` David Jander
2025-03-07 14:40 ` Dan Shelton
2025-03-05 12:03 ` Ahmad Fatoum
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7b73bca5-c1a2-4260-9c8a-510887ba4be8@pengutronix.de \
--to=a.fatoum@pengutronix.de \
--cc=barebox@lists.infradead.org \
--cc=cedric.blancher@gmail.com \
--cc=dan.f.shelton@gmail.com \
--cc=david@protonic.nl \
--cc=martin.l.wege@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox