Hi, Thank you for your comments. I'll play with array type mmap. And later will provide some solution. On Tue, Jun 22, 2021 at 12:09 PM Toke Høiland-Jørgensen wrote: > Daniel P. Berrangé writes: > > > On Tue, Jun 22, 2021 at 10:25:19AM +0200, Toke Høiland-Jørgensen wrote: > >> Jason Wang writes: > >> > >> > 在 2021/6/22 上午11:29, Yuri Benditovich 写道: > >> >> On Mon, Jun 21, 2021 at 12:20 PM Jason Wang > wrote: > >> >>> > >> >>> 在 2021/6/19 上午4:03, Andrew Melnichenko 写道: > >> >>>> Hi Jason, > >> >>>> I've checked "kernel.unprivileged_bpf_disabled=0" on Fedora, > Ubuntu, > >> >>>> and Debian - no need permissions to update BPF maps. > >> >>> > >> >>> How about RHEL :) ? > >> >> If I'm not mistaken, the RHEL releases do not use modern kernels yet > >> >> (for BPF we need 5.8+). > >> >> So this will be (probably) relevant for RHEL 9. Please correct me if > I'm wrong. > >> > > >> > Adding Toke for more ideas on this. > >> > >> Ignore the kernel version number; we backport all of BPF to RHEL, > >> basically. RHEL8.4 is up to upstream kernel 5.10, feature-wise. > >> > >> However, we completely disable unprivileged BPF on RHEL kernels. Also, > >> there's upstream commit: > >> 08389d888287 ("bpf: Add kconfig knob for disabling unpriv bpf by > default") > >> > >> which adds a new value of '2' to the unprivileged_bpf_disable sysctl. I > >> believe this may end up being the default on Fedora as well. > >> > >> So any design relying on unprivileged BPF is likely to break; I'd > >> suggest you look into how you can get this to work with CAP_BPF :) > > > > QEMU will never have any capabilities. Any resources that required > > privileges have to be opened by a separate privileged helper, and the > > open FD then passed across to the QEMU process. This relies on the > > capabilities checks only being performed at time of initial opening, > > and *not* on operations performed on the already open FD. > > That won't work for regular map updates either, unfortunately: you still > have to perform a bpf() syscall to update an element, and that is a > privileged operation. > > You may be able to get around this by using an array map type and > mmap()'ing the map contents, but I'm not sure how well that will work > across process boundaries. > > If it doesn't, I only see two possibilities: populate the map > ahead-of-time and leave it in place, or keep the privileged helper > process around to perform map updates on behalf of QEMU... > > -Toke > >