Closed dthaler closed 5 months ago
David Vernet wrote:
[Gemini] picked out stuff from other text around the web about security within the kernel, but it gave me some ideas. I suspect it might suffice to highlight things like:
- The Instruction Set Architecture may allow "bad programs" to do "bad things" with accessible memory regions or use of compute resources (infinite loops or extend expensive computation), and is not fundamentally different from any other Instruction Set Architecture in this regard.
The limited set of instructions might reduce the abuse surface somewhat, but security is left to other layers that are out of scope of this document (e.g. external verification).
Execution environments should be carefully designed to only run verified or trusted programs, and sandboxing and privilege level separation are key strategies for limiting security and abuse impact. This too is out of scope of the Instruction Set Architecture, though.
Not sure if any of that nonsense helps, but just in case ... =)
It most certainly does help. As your paragraphs say, I think it's probably reasonable to just enumerate possible issues that could result from running BPF programs, and then explain that verification, safety, etc, are out of scope and the responsibility of other layers such as the verifier. In other words, I expect this will be an "educational disclaimer" paragraph.
Strawman text also posted to the list for review: https://mailarchive.ietf.org/arch/msg/bpf/ep1ry_n82ORKtRSerr45CwcM570/
Fixed in draft-02
Found by ID-nits