| Message ID | 20220530084514.10170-2-roberto.sassu@huawei.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | BPF |
| Headers | show |
| Series | bpf: Retry access to a map in read-only mode | expand |
| Context | Check | Description |
|---|---|---|
| bpf/vmtest-bpf-next-VM_Test-3 | fail | Logs for Kernel LATEST on z15 with gcc |
| bpf/vmtest-bpf-next-PR | fail | PR summary |
| bpf/vmtest-bpf-next-VM_Test-2 | success | Logs for Kernel LATEST on ubuntu-latest with llvm-15 |
| bpf/vmtest-bpf-next-VM_Test-1 | success | Logs for Kernel LATEST on ubuntu-latest with gcc |
| netdev/tree_selection | success | Not a local patch |
On 5/30/22 10:45 AM, Roberto Sassu wrote: > Retry map access with read-only permission, if access was denied when all > permissions were requested (open_flags is set to zero). Write access might > have been denied by the bpf_map security hook. > > Some operations, such as show and dump, don't need write permissions, so > there is a good chance of success with retrying. > > Prefer this solution to extending the API, as otherwise a new mechanism > would need to be implemented to determine the right permissions for an > operation. > > Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com> > --- > tools/lib/bpf/bpf.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c > index 240186aac8e6..b4eec39021a4 100644 > --- a/tools/lib/bpf/bpf.c > +++ b/tools/lib/bpf/bpf.c > @@ -1056,6 +1056,11 @@ int bpf_map_get_fd_by_id(__u32 id) > attr.map_id = id; > > fd = sys_bpf_fd(BPF_MAP_GET_FD_BY_ID, &attr, sizeof(attr)); > + if (fd < 0) { > + attr.open_flags = BPF_F_RDONLY; > + fd = sys_bpf_fd(BPF_MAP_GET_FD_BY_ID, &attr, sizeof(attr)); > + } > + But then what about bpf_obj_get() API in libbpf? attr.file_flags has similar purpose as attr.open_flags in this case. The other issue is that this could have upgrade implications, e.g. where an application bailed out before, it is now passing wrt bpf_map_get_fd_by_id(), but then suddenly failing during map update calls. Imho, it might be better to be explicit about user intent w/o the lib doing guess work upon failure cases (... or have the BPF LSM set the attr.open_flags to BPF_F_RDONLY from within the BPF prog). > return libbpf_err_errno(fd); > } > >
> From: Daniel Borkmann [mailto:daniel@iogearbox.net] > Sent: Monday, May 30, 2022 11:55 PM > On 5/30/22 10:45 AM, Roberto Sassu wrote: > > Retry map access with read-only permission, if access was denied when all > > permissions were requested (open_flags is set to zero). Write access might > > have been denied by the bpf_map security hook. > > > > Some operations, such as show and dump, don't need write permissions, so > > there is a good chance of success with retrying. > > > > Prefer this solution to extending the API, as otherwise a new mechanism > > would need to be implemented to determine the right permissions for an > > operation. > > > > Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com> > > --- > > tools/lib/bpf/bpf.c | 5 +++++ > > 1 file changed, 5 insertions(+) > > > > diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c > > index 240186aac8e6..b4eec39021a4 100644 > > --- a/tools/lib/bpf/bpf.c > > +++ b/tools/lib/bpf/bpf.c > > @@ -1056,6 +1056,11 @@ int bpf_map_get_fd_by_id(__u32 id) > > attr.map_id = id; > > > > fd = sys_bpf_fd(BPF_MAP_GET_FD_BY_ID, &attr, sizeof(attr)); > > + if (fd < 0) { > > + attr.open_flags = BPF_F_RDONLY; > > + fd = sys_bpf_fd(BPF_MAP_GET_FD_BY_ID, &attr, sizeof(attr)); > > + } > > + > > But then what about bpf_obj_get() API in libbpf? attr.file_flags has similar > purpose as attr.open_flags in this case. Ok, I missed it. > The other issue is that this could have upgrade implications, e.g. where an > application bailed out before, it is now passing wrt bpf_map_get_fd_by_id(), > but then suddenly failing during map update calls. Good point. > Imho, it might be better to be explicit about user intent w/o the lib doing > guess work upon failure cases (... or have the BPF LSM set the attr.open_flags > to BPF_F_RDONLY from within the BPF prog). Uhm, I don't like that the users should be aware of permissions assigned to maps that they don't own. Maybe, better the original idea, request read-only permission for the list and dump operations. Roberto HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Li Peng, Zhong Ronghua
diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c index 240186aac8e6..b4eec39021a4 100644 --- a/tools/lib/bpf/bpf.c +++ b/tools/lib/bpf/bpf.c @@ -1056,6 +1056,11 @@ int bpf_map_get_fd_by_id(__u32 id) attr.map_id = id; fd = sys_bpf_fd(BPF_MAP_GET_FD_BY_ID, &attr, sizeof(attr)); + if (fd < 0) { + attr.open_flags = BPF_F_RDONLY; + fd = sys_bpf_fd(BPF_MAP_GET_FD_BY_ID, &attr, sizeof(attr)); + } + return libbpf_err_errno(fd); }
Retry map access with read-only permission, if access was denied when all permissions were requested (open_flags is set to zero). Write access might have been denied by the bpf_map security hook. Some operations, such as show and dump, don't need write permissions, so there is a good chance of success with retrying. Prefer this solution to extending the API, as otherwise a new mechanism would need to be implemented to determine the right permissions for an operation. Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com> --- tools/lib/bpf/bpf.c | 5 +++++ 1 file changed, 5 insertions(+)