RE: BPF ISA Security Considerations section

[dthaler1968@googlemail.com]

> -----Original Message-----
> From: David Vernet <void@manifault.com>
> Sent: Sunday, April 21, 2024 9:52 AM
> To: dthaler1968@googlemail.com
> Cc: bpf@ietf.org; bpf@vger.kernel.org
> Subject: Re: BPF ISA Security Considerations section
> 
> On Sat, Apr 20, 2024 at 09:08:56AM -0700, dthaler1968@googlemail.com
wrote:
> > Per
> > https://authors.ietf.org/en/required-content#security-considerations,
> > the BPF ISA draft is required to have a Security Considerations
> > section before it can become an RFC.
> >
> > Below is strawman text that tries to strike a balance between
> > discussing security issues and solutions vs keeping details out of
> > scope that belong in other documents like the "verifier expectations
> > and building blocks for allowing safe execution of untrusted BPF
> > programs" document that is a separate item on the IETF WG charter.
> >
> > Proposed text:
> 
> Hi Dave,
> 
> Thanks for writing this up. Overall it looks great, just had one comment
below.
> 
> > > Security Considerations
> > >
> > > BPF programs could use BPF instructions to do malicious things with
> > > memory, CPU, networking, or other system resources. This is not
> > > fundamentally different  from any other type of software that may
> > > run on a device. Execution environments should be carefully designed
> > > to only run BPF programs that are trusted or verified, and
> > > sandboxing and privilege level separation are key strategies for
> > > limiting security and abuse impact. For example, BPF verifiers are
> > > well-known and widely deployed and are responsible for ensuring that
> > > BPF programs will terminate within a reasonable time, only interact
> > > with memory in safe ways, and adhere to platform-specified API
> > > contracts. The details are out of scope of this document (but see
> > > [LINUX] and [PREVAIL]), but this level of verification can often
> > > provide a stronger level of security assurance than for other
> > > software and operating system code.
> > >
> > > Executing programs using the BPF instruction set also requires
> > > either an interpreter or a JIT compiler to translate them to
> > > hardware processor native instructions. In general, interpreters are
> > > considered a source of insecurity (e.g., gadgets susceptible to
> > > side-channel attacks due to speculative execution) and are not
> > > recommended.
> 
> Do we need to say that it's not recommended to use JIT engines? Given that
this is
> explaining how BPF programs are executed, to me it reads a bit as saying,
"It's not
> recommended to use BPF." Is it not sufficient to just explain the risks?

It says it's not recommended to use interpreters.
I couldn't tell if your comment was a typo, did you mean interpreters or JIT
engines?
It should read as saying it's recommended to use a JIT engine rather than an
interpreter.

Do you have a suggested alternate wording?

Dave