Mount NFSv4.2 filesystem in barebox?

Mount NFSv4.2 filesystem in barebox?

[Martin Wege]

Hello!

Does barebox have support to mount a NFSv.2 filesystem?

Thanks,
Martin

Re: Mount NFSv4.2 filesystem in barebox?

[Sascha Hauer]

Hi Martin,

On Tue, Feb 11, 2025 at 01:56:58PM +0100, Martin Wege wrote:
> Hello!
> 
> Does barebox have support to mount a NFSv.2 filesystem?

No, not yet. For NFSv4 we would first need TCP support. While we started
to integrate a TCP stack we are not there yet unfortunately.

Regards,
 Sascha

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

Re: Mount NFSv4.2 filesystem in barebox?

[Martin Wege]

On Wed, Feb 12, 2025 at 3:33 PM Sascha Hauer <s.hauer@pengutronix.de> wrote:
>
> Hi Martin,
>
> On Tue, Feb 11, 2025 at 01:56:58PM +0100, Martin Wege wrote:
> > Hello!
> >
> > Does barebox have support to mount a NFSv.2 filesystem?
>
> No, not yet. For NFSv4 we would first need TCP support. While we started
> to integrate a TCP stack we are not there yet unfortunately.

How long is this going to take?

https://github.com/sahlberg/libnfs has NFSv4.1 support, just remove
the NFSv3,v2 bits, both are considered obsolete by the IETF.

Thanks,
Martin

Re: Mount NFSv4.2 filesystem in barebox?

[Sascha Hauer]

On Fri, Feb 21, 2025 at 12:54:00PM +0100, Martin Wege wrote:
> On Wed, Feb 12, 2025 at 3:33 PM Sascha Hauer <s.hauer@pengutronix.de> wrote:
> >
> > Hi Martin,
> >
> > On Tue, Feb 11, 2025 at 01:56:58PM +0100, Martin Wege wrote:
> > > Hello!
> > >
> > > Does barebox have support to mount a NFSv.2 filesystem?
> >
> > No, not yet. For NFSv4 we would first need TCP support. While we started
> > to integrate a TCP stack we are not there yet unfortunately.
> 
> How long is this going to take?

I don't think this will happen anytime soon. It's quite some work and
our bandwidth for adding such a feature without (paying) customer
demand is limited.

That said, the lack of NFSv4 support is nagging me personally as well.

Sascha

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

Re: Mount NFSv4.2 filesystem in barebox?

[Ahmad Fatoum]

Hi,

On 28.02.25 11:57, Sascha Hauer wrote:
> On Fri, Feb 21, 2025 at 12:54:00PM +0100, Martin Wege wrote:
>> On Wed, Feb 12, 2025 at 3:33 PM Sascha Hauer <s.hauer@pengutronix.de> wrote:
>>>
>>> Hi Martin,
>>>
>>> On Tue, Feb 11, 2025 at 01:56:58PM +0100, Martin Wege wrote:
>>>> Hello!
>>>>
>>>> Does barebox have support to mount a NFSv.2 filesystem?
>>>
>>> No, not yet. For NFSv4 we would first need TCP support. While we started
>>> to integrate a TCP stack we are not there yet unfortunately.
>>
>> How long is this going to take?
> 
> I don't think this will happen anytime soon. It's quite some work and
> our bandwidth for adding such a feature without (paying) customer
> demand is limited.
> 
> That said, the lack of NFSv4 support is nagging me personally as well.

We had a discussion about this last year, but it didn't result in any
upstream code yet:
https://lore.barebox.org/barebox/CAAvCNcCZhS8mkvdgcJ2L-eiur+OxgWEXRLnadO_HFyHfSi7WFA@mail.gmail.com/

One question that I still have, is what do you use NFSv4 for?
Is it just for development and your IT is disabling NFSv3?

Do you use it in the field?

Knowing about the use case helps with prioritizing future work.
As it stands, NFS is mostly understood as development feature and
it's expected so far that interested users will be able to provide
a NFSv3 UDP server in their development network.

Thanks,
Ahmad



> 
> Sascha
> 


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

Re: Mount NFSv4.2 filesystem in barebox?

[Martin Wege]

On Mon, Mar 3, 2025 at 9:40 AM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
>
> Hi,
>
> On 28.02.25 11:57, Sascha Hauer wrote:
> > On Fri, Feb 21, 2025 at 12:54:00PM +0100, Martin Wege wrote:
> >> On Wed, Feb 12, 2025 at 3:33 PM Sascha Hauer <s.hauer@pengutronix.de> wrote:
> >>>
> >>> Hi Martin,
> >>>
> >>> On Tue, Feb 11, 2025 at 01:56:58PM +0100, Martin Wege wrote:
> >>>> Hello!
> >>>>
> >>>> Does barebox have support to mount a NFSv.2 filesystem?
> >>>
> >>> No, not yet. For NFSv4 we would first need TCP support. While we started
> >>> to integrate a TCP stack we are not there yet unfortunately.
> >>
> >> How long is this going to take?
> >
> > I don't think this will happen anytime soon. It's quite some work and
> > our bandwidth for adding such a feature without (paying) customer
> > demand is limited.
> >
> > That said, the lack of NFSv4 support is nagging me personally as well.
>
> We had a discussion about this last year, but it didn't result in any
> upstream code yet:
> https://lore.barebox.org/barebox/CAAvCNcCZhS8mkvdgcJ2L-eiur+OxgWEXRLnadO_HFyHfSi7WFA@mail.gmail.com/
>
> One question that I still have, is what do you use NFSv4 for?
> Is it just for development and your IT is disabling NFSv3?

No, NFSv4.1 (NFSv4.0 is obsolete due to bugs) offers better
performance, more flexibility, smaller footprint, better caching
(delegations), ACLs, SELinux support, and can be tunneled through
firewalls because it only uses TCP port 2049 and nothing else.

>
> Do you use it in the field?

Yes, we do

>
> Knowing about the use case helps with prioritizing future work.
> As it stands, NFS is mostly understood as development feature and
> it's expected so far that interested users will be able to provide
> a NFSv3 UDP server in their development network.

No, NFS is not only a development feature. For example CERN uses NFS
boot (with patched NFSv4.1 stack) in radiation environments - that
saves a SSD per embedded machine, which is typically one of the most
affected pieces from radiation. AIRBUS also uses nfsboot in their
equipment and flight deck systems.

So yes, you would have customers for NFSv4.1 support in barebox.

Thanks,
Martin

Re: Mount NFSv4.2 filesystem in barebox?

[David Jander]

Dear Martin,

On Tue, 4 Mar 2025 22:50:00 +0100
Martin Wege <martin.l.wege@gmail.com> wrote:

> On Mon, Mar 3, 2025 at 9:40 AM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
> >
> > Hi,
> >
> > On 28.02.25 11:57, Sascha Hauer wrote:  
> > > On Fri, Feb 21, 2025 at 12:54:00PM +0100, Martin Wege wrote:  
> > >> On Wed, Feb 12, 2025 at 3:33 PM Sascha Hauer <s.hauer@pengutronix.de> wrote:  
> > >>>
> > >>> Hi Martin,
> > >>>
> > >>> On Tue, Feb 11, 2025 at 01:56:58PM +0100, Martin Wege wrote:  
> > >>>> Hello!
> > >>>>
> > >>>> Does barebox have support to mount a NFSv.2 filesystem?  
> > >>>
> > >>> No, not yet. For NFSv4 we would first need TCP support. While we started
> > >>> to integrate a TCP stack we are not there yet unfortunately.  
> > >>
> > >> How long is this going to take?  
> > >
> > > I don't think this will happen anytime soon. It's quite some work and
> > > our bandwidth for adding such a feature without (paying) customer
> > > demand is limited.
> > >
> > > That said, the lack of NFSv4 support is nagging me personally as well.  
> >
> > We had a discussion about this last year, but it didn't result in any
> > upstream code yet:
> > https://lore.barebox.org/barebox/CAAvCNcCZhS8mkvdgcJ2L-eiur+OxgWEXRLnadO_HFyHfSi7WFA@mail.gmail.com/
> >
> > One question that I still have, is what do you use NFSv4 for?
> > Is it just for development and your IT is disabling NFSv3?  
> 
> No, NFSv4.1 (NFSv4.0 is obsolete due to bugs) offers better
> performance, more flexibility, smaller footprint, better caching
> (delegations), ACLs, SELinux support, and can be tunneled through
> firewalls because it only uses TCP port 2049 and nothing else.
> 
> >
> > Do you use it in the field?  
> 
> Yes, we do
> 
> >
> > Knowing about the use case helps with prioritizing future work.
> > As it stands, NFS is mostly understood as development feature and
> > it's expected so far that interested users will be able to provide
> > a NFSv3 UDP server in their development network.  
> 
> No, NFS is not only a development feature. For example CERN uses NFS
> boot (with patched NFSv4.1 stack) in radiation environments - that
> saves a SSD per embedded machine, which is typically one of the most
> affected pieces from radiation. AIRBUS also uses nfsboot in their
> equipment and flight deck systems.
> 
> 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...

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

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.

Best regards,

-- 
David Jander

Re: Mount NFSv4.2 filesystem in barebox?

[Ahmad Fatoum]

Hello Martin,

On 04.03.25 22:50, Martin Wege wrote:
> On Mon, Mar 3, 2025 at 9:40 AM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
>> We had a discussion about this last year, but it didn't result in any
>> upstream code yet:
>> https://lore.barebox.org/barebox/CAAvCNcCZhS8mkvdgcJ2L-eiur+OxgWEXRLnadO_HFyHfSi7WFA@mail.gmail.com/
>>
>> One question that I still have, is what do you use NFSv4 for?
>> Is it just for development and your IT is disabling NFSv3?
> 
> No, NFSv4.1 (NFSv4.0 is obsolete due to bugs) offers better
> performance, more flexibility, smaller footprint, better caching
> (delegations), ACLs, SELinux support, and can be tunneled through
> firewalls because it only uses TCP port 2049 and nothing else.

I am speaking in particular about NFS use in barebox itself,
where you'll likely to not benefit from better caching, ACLs, SELinux
support and so on. The kernel NFS server can provide both v3 and v4
in parallel and you can already set in barebox

  global.linux.rootnfsopts="v4,tcp"

So the booted kernel need not have any NFSv3 UDP support at all.

As David mentioned using TFTP in barebox instead of NFS is an option
as well for as long there is no NFSv4 support if NFSv3 is a no-go.

>> Do you use it in the field?
> 
> Yes, we do

So, you use barebox to load a kernel from NFS and then use the same
NFS as rootfs in production and currently you are using NFSv3
for both?

>> Knowing about the use case helps with prioritizing future work.
>> As it stands, NFS is mostly understood as development feature and
>> it's expected so far that interested users will be able to provide
>> a NFSv3 UDP server in their development network.
> 
> No, NFS is not only a development feature. For example CERN uses NFS
> boot (with patched NFSv4.1 stack) in radiation environments - that
> saves a SSD per embedded machine, which is typically one of the most
> affected pieces from radiation. AIRBUS also uses nfsboot in their
> equipment and flight deck systems.

We also use NFS at work for the developer workstations. My question
is strictly about _your_ NFS usage in barebox.

> So yes, you would have customers for NFSv4.1 support in barebox.

Just to clarify: I would love to see barebox support TCP and newer NFS
versions and if someone were to contribute that, I'd be happy to help with
testing and review to see it merged upstream.

So far, we had three threads on the mailing list, where users asked about
our plans. However, I haven't managed to find out how in particular they
currently use the NFS support in barebox.

We (as in the barebox maintainers) haven't been approached by a paying
customer interested in adding that support. That means, the topic has
to compete against other features we are interested in adding to barebox.

So far, NFSv4 has been low priority for us (TCP itself is not though and
I hope we might get there this year). So the way forward is either:

  - A user contributes support
  - A customer pays for the support
  - Users describe their use cases, so we as maintainers can better
    assess how useful NFSv4 support would be for barebox as a project

Thanks,
Ahmad


> 
> Thanks,
> Martin
> 


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

Re: Mount NFSv4.2 filesystem in barebox?

[Ahmad Fatoum]

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 |

Re: Mount NFSv4.2 filesystem in barebox?

[David Jander]

Hi Ahmad,

On Wed, 5 Mar 2025 13:51:51 +0100
Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:

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

Thanks :-)

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

Aha. Interesting. I suppose you mean network boot of signed images from
something like NFS (a complex filesystem) as opposed to TFTP (which is more
akin to a raw partition in terms of simplicity of the protocol)? Or is TFTP
already outside of the security comfort zone of barebox?

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

I agree that if secure-boot is involved, the net-boot solution for barebox
should be the most simple protocol possible so that we always have some
transport implementation that can be hardened with the lowest effort, whether
that is TFTP or HTTP(S). It surely won't be NFSv4.2+kerberos or anything like
that. Still, there are likely a lot of cases, where a physical access barrier
is secure enough, and bare NFS can be used, so let's not immediately shoot
down the idea of having an NFSv4 client in barebox ;-)

A basic HTTP get-only client implementation is probably simple enough
without the (S) part if the sole purpose is to download a signed fit image?

Of course, the server part for boot purposes should probably also be a small,
trusted code-base and not something like a full-blown webserver, full of
enormous attack surfaces due to the lack of TLS.

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

It already arrived :-)
Thanks.

Best regards,

-- 
David Jander

Re: Mount NFSv4.2 filesystem in barebox?

[Dan Shelton]

On Wed, 5 Mar 2025 at 14:55, David Jander <david@protonic.nl> wrote:
>
>
> Hi Ahmad,
>
> On Wed, 5 Mar 2025 13:51:51 +0100
> Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
>
> > 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. :-)
>
> Thanks :-)
>
> > > 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.
>
> Aha. Interesting. I suppose you mean network boot of signed images from
> something like NFS (a complex filesystem) as opposed to TFTP (which is more
> akin to a raw partition in terms of simplicity of the protocol)? Or is TFTP
> already outside of the security comfort zone of barebox?

TFTP is outside the comfort zone of almost every enterprise IT. Most
of Intel&Win&co label it as "legacy" for a reason

>
> > > 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.
>
> I agree that if secure-boot is involved, the net-boot solution for barebox
> should be the most simple protocol possible so that we always have some
> transport implementation that can be hardened with the lowest effort, whether
> that is TFTP or HTTP(S).

1. HTTPS is not always viable, in case of firewalls which unpack, add
headers or content, and then repack HTTPS traffic. Given that kind of
problem HTTPS is often unuseable. Plus, many managements no longer
trusts HTTPS, because it has become a jack of all trades, and a gaping
security hole for all trades.
2. Booting or getting a boot image via HTTPS is basically not a
standard, NFSv4 is at least IETF+RFC+already in use. barebox is just
late in that game

> It surely won't be NFSv4.2+kerberos or anything like
> that. Still, there are likely a lot of cases, where a physical access barrier
> is secure enough, and bare NFS can be used, so let's not immediately shoot
> down the idea of having an NFSv4 client in barebox ;-)

There is NFSv4+TLS, which should be pretty easy to implement, because
it is just sticking TLS in front of libtirpc

Dan
-- 
Dan Shelton - Cluster Specialist Win/Lin/Bsd