Re: BPF ISA Security Considerations section

[David Vernet <void@manifault.com>]

[-- Attachment #1: Type: text/plain, Size: 2356 bytes --]

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?

Thanks,
David

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]