mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Ahmad Fatoum <a.fatoum@pengutronix.de>
To: David Jander <david@protonic.nl>
Cc: Barebox List <barebox@lists.infradead.org>,
	Cedric Blancher <cedric.blancher@gmail.com>,
	Dan Shelton <dan.f.shelton@gmail.com>,
	Martin Wege <martin.l.wege@gmail.com>
Subject: Re: Mount NFSv4.2 filesystem in barebox?
Date: Tue, 8 Apr 2025 11:28:28 +0200	[thread overview]
Message-ID: <9d01a2d4-6ad7-4b80-b212-ea473e228f33@pengutronix.de> (raw)
In-Reply-To: <20250305145543.30c3c8fa@erd003.prtnl>

Hi David,

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



  parent reply	other threads:[~2025-04-08  9:34 UTC|newest]

Thread overview: 12+ 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
2025-03-05 13:55               ` David Jander
2025-03-07 14:40                 ` Dan Shelton
2025-04-08  9:28                 ` Ahmad Fatoum [this message]
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=9d01a2d4-6ad7-4b80-b212-ea473e228f33@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