Mount NFSv4.2 filesystem in barebox?

[Ahmad Fatoum]

Hi David,

On 05.03.25 14:55, David Jander wrote:
> On Wed, 5 Mar 2025 13:51:51 +0100
> Ahmad Fatoum <a.fatoum at pengutronix.de> wrote:
>> 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?

There has been some external fuzzing of barebox network functionality, e.g.
https://www.ndss-symposium.org/wp-content/uploads/2025-330-paper.pdf

We need to do this in a more systematic fashion, which means go through
all parsers in the secure boot path and fuzz them in an automated manner
as new code is integrated.

TFTP should eventually be part of that, but focus for now is on defining
some "normal" secure boot path, fuzzing it and upstreaming the infrastructure,
where normal is defines as raw FIT partition in a GPT/MBR on an eMMC.

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

No shooting down, just explaining my view of things. :)

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

There has been multiple TCP/HTTP attempts in the past, it would be nice
to get something into shape enough that something can finally be integrated
upstream.

Cheers,
Ahmad



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