Em Mon, Dec 06, 2021 at 12:40:40PM -0800, John Fastabend escreveu: > I'll just reiterate (I think you get it though) that simply signing > enforcement doesn't mean now BPF is safe. Further these programs I think this was clear from the get go, at most this would help with fingerpointing :-) I.e. BPF signing is not about making things safer, its just an attempt to know who messed up. > have very high privileges and can do all sorts of things to the > system. But, sure sig enforcement locks down one avenue of loading > bogus program. > > the capability of calling bpf(). Trying to define heuristics is also > > not good enough for us - creative malicious actors have a tendency to > > come up with ways to chain things that individually are allowed and > > benign, but combined in a way that you just couldn't foresee. It would > Sure, but I would argue some things can be very restrictive and > generally useful. For example, never allow kernel memory read could be > enforced from BPF side directly. Never allow pkt redirect, etc. But this is something unrelated to BPF signing, right? Its something desirable, I'd say this will be at some point required, i.e. one more step in having BPF programs to be more like userspace apps, where you can limit all sorts of things it can do, programmatically, a BPF ulimit, hey, blimit? - Arnaldo
