Re: BPF ISA Security Considerations section

[David Vernet <void@manifault.com>]

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

On Mon, Apr 22, 2024 at 11:37:48AM -0700, dthaler1968@googlemail.com wrote:
> David Vernet <void@manifault.com> wrote:
> > > 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.

Sorry, yes, I meant to say interpreters. What I really meant though is
that discussing the safety of JIT engines vs. interpreters seems a bit
out of scope for this Security Considerations section. It's not as
though JIT is a foolproof method in and of itself.

> > Do you have a suggested alternate wording?

How about this:

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 and JIT engines can be a
source of insecurity (e.g., gadgets susceptible to side-channel attacks
due to speculative execution, or W^X mappings), and should be audited
carefully for vulnerabilities.

> How about:
> 
> OLD: In general, interpreters are considered a
> OLD: source of insecurity (e.g., gadgets susceptible to side-channel attacks
> due to speculative execution)
> OLD: and are not recommended.
> 
> NEW: In general, interpreters are considered a
> NEW: source of insecurity (e.g., gadgets susceptible to side-channel attacks
> due to speculative execution)
> NEW: so use of a JIT compiler is recommended instead.

This is fine too. My only worry is that there have also been plenty of
vulnerabilities exploited against JIT engines as well, so it might be
more prudent to just warn the reader of the risks of interpreters/JITs
in general as opposed to prescribing one over the other.

What do you think?

Thanks,
David

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