On Fri, Oct 5, 2018 at 4:21 PM Lorenz Bauer <lmb@xxxxxxxxxxxxxx> wrote: > On Fri, 5 Oct 2018 at 15:12, Jann Horn <jannh@xxxxxxxxxx> wrote: > > On Fri, Oct 5, 2018 at 9:42 AM Lorenz Bauer <lmb@xxxxxxxxxxxxxx> wrote: > > > On Tue, 2 Oct 2018 at 21:00, Jann Horn <jannh@xxxxxxxxxx> wrote: > > > > If this is for testing only, you can slap a capable(CAP_SYS_ADMIN) > > > > check in here, right? I doubt it matters, but I don't really like > > > > seeing something like this exposed to unprivileged userspace just > > > > because you need it for kernel testing. > > > > > > That would mean all tests have to run as root / with CAP_SYS_ADMIN > > > which isn't ideal. > > > > This patch basically means that it becomes easier for a local user to > > construct a BPF hash table that has all of its values stuffed into a > > single hash bucket, correct? Which makes it easier to create a BPF > > program that generates unusually large RCU stalls by performing ~40000 > > BPF map lookups, each of which has to walk through the entire linked > > list of the hash map bucket? I dislike exposing something like that to > > unprivileged userspace. > > That's a good point, for which I don't have an answer. You could argue that > this was the status quo until the seed was randomised, so it seems > like this hasn't been a worry so far. Should it be going forward? I don't think that local DoS bugs, or bugs that locally degrade performance, are a big deal, but I also think that the kernel should try to avoid having such issues. > > And if you want to run the whole BPF test suite with all its tests, > > don't you already need root privileges? Or is this a different test > > suite? > > No, I'm thinking about third parties that want to test their own BPF. Ah. That wasn't clear to me from your patch description. Can you please describe exactly why something that is not a kernel unit test needs deterministic BPF hash map behavior? > If you enable unprivileged BPF you can use BPF_PROG_TEST_RUN to > test your programs without root, if I'm not mistaken.
