BPF List
 help / color / mirror / Atom feed
From: dthaler1968@googlemail.com
To: <bpf@ietf.org>, <bpf@vger.kernel.org>
Subject: BPF ISA Security Considerations section
Date: Sat, 20 Apr 2024 09:08:56 -0700	[thread overview]
Message-ID: <093301da933d$0d478510$27d68f30$@gmail.com> (raw)

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:

> 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.
>
> Informative References:
>
> [LINUX] "eBPF verifier",
https://www.kernel.org/doc/html/latest/bpf/verifier.html
>
> [PREVAIL] Elazar Gershuni, Nadav Amit, Arie Gurfinkel, Nina Narodytska,
Jorge
>    A. Navas, Noam Rinetzky, Leonid Ryzhyk, and Mooly Sagiv. "Simple and
Precise
>    Static Analysis of Untrusted Linux Kernel Extensions." In Proceedings
of the 40th
>    ACM SIGPLAN Conference on Programming Language Design and
Implementation,
>    pp. 1069-1084. 2019.
>
https://pldi19.sigplan.org/details/pldi-2019-papers/44/Simple-and-Precise-St
atic-Analysis-of-Untrusted-Linux-Kernel-Extensions

Dave


WARNING: multiple messages have this Message-ID (diff)
From: dthaler1968=40googlemail.com@dmarc.ietf.org
To: <bpf@ietf.org>, <bpf@vger.kernel.org>
Subject: [Bpf] BPF ISA Security Considerations section
Date: Sat, 20 Apr 2024 09:08:56 -0700	[thread overview]
Message-ID: <093301da933d$0d478510$27d68f30$@gmail.com> (raw)
Message-ID: <20240420160856.OCYLYqPoNmVbiSCsbAdobYXJQyrOqfri8e5rfAMXNiw@z> (raw)

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:

> 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.
>
> Informative References:
>
> [LINUX] "eBPF verifier",
https://www.kernel.org/doc/html/latest/bpf/verifier.html
>
> [PREVAIL] Elazar Gershuni, Nadav Amit, Arie Gurfinkel, Nina Narodytska,
Jorge
>    A. Navas, Noam Rinetzky, Leonid Ryzhyk, and Mooly Sagiv. "Simple and
Precise
>    Static Analysis of Untrusted Linux Kernel Extensions." In Proceedings
of the 40th
>    ACM SIGPLAN Conference on Programming Language Design and
Implementation,
>    pp. 1069-1084. 2019.
>
https://pldi19.sigplan.org/details/pldi-2019-papers/44/Simple-and-Precise-St
atic-Analysis-of-Untrusted-Linux-Kernel-Extensions

Dave

-- 
Bpf mailing list
Bpf@ietf.org
https://www.ietf.org/mailman/listinfo/bpf

             reply	other threads:[~2024-04-20 16:08 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-20 16:08 dthaler1968 [this message]
2024-04-20 16:08 ` [Bpf] BPF ISA Security Considerations section dthaler1968=40googlemail.com
2024-04-21 16:51 ` David Vernet
2024-04-21 16:51   ` [Bpf] " David Vernet
2024-04-21 17:20   ` dthaler1968
2024-04-21 17:20     ` [Bpf] " dthaler1968=40googlemail.com
2024-04-22 18:37     ` dthaler1968
2024-04-22 18:37       ` [Bpf] " dthaler1968=40googlemail.com
2024-04-22 18:49       ` Watson Ladd
2024-04-22 18:49         ` Watson Ladd
2024-04-22 19:34       ` David Vernet
2024-04-22 19:34         ` [Bpf] " David Vernet
2024-04-22 20:26         ` dthaler1968
2024-04-22 20:26           ` [Bpf] " dthaler1968=40googlemail.com
2024-04-22 20:32           ` dthaler1968
2024-04-22 20:32             ` [Bpf] " dthaler1968=40googlemail.com
2024-04-23  0:19             ` Watson Ladd
2024-04-23  0:19               ` Watson Ladd
2024-04-23 16:00               ` [EXTERNAL] " Alan Jowett
2024-04-23 16:00                 ` [Bpf] [EXTERNAL] " Alan Jowett
2024-04-23 17:59               ` [Bpf] " dthaler1968
2024-04-23 17:59                 ` dthaler1968=40googlemail.com
2024-04-23 19:59                 ` David Vernet
2024-04-23 19:59                   ` David Vernet
2024-04-22 19:01 ` Watson Ladd
2024-04-22 19:01   ` Watson Ladd
2024-04-22 19:05   ` dthaler1968
2024-04-22 19:05     ` dthaler1968=40googlemail.com
2024-04-23  1:01     ` Watson Ladd

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='093301da933d$0d478510$27d68f30$@gmail.com' \
    --to=dthaler1968@googlemail.com \
    --cc=bpf@ietf.org \
    --cc=bpf@vger.kernel.org \
    /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