• Daniel Borkmann's avatar
    bpf: split state from prandom_u32() and consolidate {c, e}BPF prngs · 3ad00405
    Daniel Borkmann authored
    While recently arguing on a seccomp discussion that raw prandom_u32()
    access shouldn't be exposed to unpriviledged user space, I forgot the
    fact that SKF_AD_RANDOM extension actually already does it for some time
    in cBPF via commit 4cd3675e ("filter: added BPF random opcode").
    
    Since prandom_u32() is being used in a lot of critical networking code,
    lets be more conservative and split their states. Furthermore, consolidate
    eBPF and cBPF prandom handlers to use the new internal PRNG. For eBPF,
    bpf_get_prandom_u32() was only accessible for priviledged users, but
    should that change one day, we also don't want to leak raw sequences
    through things like eBPF maps.
    
    One thought was also to have own per bpf_prog states, but due to ABI
    reasons this is not easily possible, i.e. the program code currently
    cannot access bpf_prog itself, and copying the rnd_state to/from the
    stack scratch space whenever a program uses the prng seems not really
    worth the trouble and seems too hacky. If needed, taus113 could in such
    cases be implemented within eBPF using a map entry to keep the state
    space, or get_random_bytes() could become a second helper in cases where
    performance would not be critical.
    
    Both sides can trigger a one-time late init via prandom_init_once() on
    the shared state. Performance-wise, there should even be a tiny gain
    as bpf_user_rnd_u32() saves one function call. The PRNG needs to live
    inside the BPF core since kernels could have a NET-less config as well.
    Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
    Acked-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
    Acked-by: default avatarAlexei Starovoitov <ast@plumgrid.com>
    Cc: Chema Gonzalez <chema@google.com>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    3ad00405
helpers.c 4.83 KB