Re: [PATCH bpf-next v5 6/7] selftests/bpf: Add tests for bpf_rcu_read_lock()

[Yonghong Song <yhs@meta.com>]

On 11/14/22 10:50 PM, Martin KaFai Lau wrote:
> On 11/11/22 8:58 AM, Yonghong Song wrote:
>> diff --git a/tools/testing/selftests/bpf/progs/rcu_read_lock.c 
>> b/tools/testing/selftests/bpf/progs/rcu_read_lock.c
>> new file mode 100644
>> index 000000000000..c11b4f8f9a9d
>> --- /dev/null
>> +++ b/tools/testing/selftests/bpf/progs/rcu_read_lock.c
>> @@ -0,0 +1,355 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/* Copyright (c) 2022 Meta Platforms, Inc. and affiliates. */
>> +
>> +#include "vmlinux.h"
>> +#include <bpf/bpf_helpers.h>
>> +#include <bpf/bpf_tracing.h>
>> +#include "bpf_tracing_net.h"
>> +#include "bpf_misc.h"
>> +
>> +char _license[] SEC("license") = "GPL";
>> +
>> +struct {
>> +    __uint(type, BPF_MAP_TYPE_CGRP_STORAGE);
>> +    __uint(map_flags, BPF_F_NO_PREALLOC);
>> +    __type(key, int);
>> +    __type(value, long);
>> +} map_a SEC(".maps");
>> +
>> +struct {
>> +    __uint(type, BPF_MAP_TYPE_TASK_STORAGE);
>> +    __uint(map_flags, BPF_F_NO_PREALLOC);
>> +    __type(key, int);
>> +    __type(value, long);
>> +} map_b SEC(".maps");
>> +
>> +__u32 user_data, key_serial, target_pid = 0;
>> +__u64 flags, result = 0;
>> +
>> +struct bpf_key *bpf_lookup_user_key(__u32 serial, __u64 flags) __ksym;
>> +void bpf_key_put(struct bpf_key *key) __ksym;
>> +void bpf_rcu_read_lock(void) __ksym;
>> +void bpf_rcu_read_unlock(void) __ksym;
>> +
>> +SEC("?fentry.s/" SYS_PREFIX "sys_getpgid")
>> +int cgrp_succ(void *ctx)
>> +{
>> +    struct task_struct *task;
>> +    struct css_set *cgroups;
>> +    struct cgroup *dfl_cgrp;
>> +    long init_val = 2;
>> +    long *ptr;
>> +
>> +    task = bpf_get_current_task_btf();
>> +    if (task->pid != target_pid)
>> +        return 0;
>> +
>> +    bpf_rcu_read_lock();
>> +    cgroups = task->cgroups;
>> +    dfl_cgrp = cgroups->dfl_cgrp;
>> +    bpf_rcu_read_unlock();
> 
> Outside of the rcu section, "cgroups" could have been gone.  Is it 
> possible that "dfl_cgrp" could be gone together with "cgroups"?

In this particular case, looks like the best is indeed
to get a reference for dfl_cgrp before doing bpf_rcu_read_unlock.
But to decide whether a particular non-rcu pointer needs
reference or not needs kernel internal knowledge for
that particular context.

So right now, the approach is to take the approach
for generic ptr_to_btf_id approach. That is, the
non-rcu pointer after rcu pointer tracing is 'trusted'.
The user can always increase bpf_rcu_read_lock() region
by himself to cover the case if the non-rcu pointer
is untrusted.

> 
>> +    ptr = bpf_cgrp_storage_get(&map_a, dfl_cgrp, &init_val,
>> +                   BPF_LOCAL_STORAGE_GET_F_CREATE);
>> +    if (!ptr)
>> +        return 0;
>> +    ptr = bpf_cgrp_storage_get(&map_a, dfl_cgrp, 0, 0);
>> +    if (!ptr)
>> +        return 0;
>> +    result = *ptr;
>> +    return 0;
>> +}
>> +
> 
> [ ... ]
> 
>> +SEC("?fentry.s/" SYS_PREFIX "sys_getpgid")
>> +int miss_unlock(void *ctx)
>> +{
>> +    struct task_struct *task;
>> +    struct css_set *cgroups;
>> +    struct cgroup *dfl_cgrp;
>> +
>> +    /* missing bpf_rcu_read_unlock() */
>> +    bpf_rcu_read_lock();
> 
> 
>> +    task = bpf_get_current_task_btf();
>> +    bpf_rcu_read_lock();
> 
> One of the bpf_rcu_read_lock() needs to be removed.  Otherwise, I think 
> the verifier will error on the nested rcu read lock first instead of 
> testing the missing unlock case here.

Thanks, will do.

> 
>> +    cgroups = task->cgroups;
>> +    bpf_rcu_read_unlock();
>> +    dfl_cgrp = cgroups->dfl_cgrp;
>> +    (void)bpf_cgrp_storage_get(&map_a, dfl_cgrp, 0,
>> +                   BPF_LOCAL_STORAGE_GET_F_CREATE);
>> +    return 0;
>> +}
>