在 2021/6/22 上午11:29, Yuri Benditovich 写道:
On Mon, Jun 21, 2021 at 12:20 PM Jason Wang <jasow...@redhat.com> 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.
Thanks
Thanks
On Wed, Jun 16, 2021 at 1:18 AM Andrew Melnichenko <and...@daynix.com
<mailto:and...@daynix.com>> wrote:
Hi,
I may miss something.
But RSS requires to update the map. This won't work if you
don't grant
any permission to qemu.
Thanks
Partly - with "kernel.unprivileged_bpf_disabled=0" capabilities is
not required to update maps.
With "kernel.unprivileged_bpf_disabled=1" - setting maps will
fail(without CAP_BPF) and "in-qemu" RSS will be used.
On Tue, Jun 15, 2021 at 12:13 PM Jason Wang <jasow...@redhat.com
<mailto:jasow...@redhat.com>> wrote:
在 2021/6/12 上午12:49, Andrew Melnichenko 写道:
> Hi,
>
> So I think the series is for unprivileged_bpf disabled.
If I'm not
> wrong, I guess the policy is to grant CAP_BPF but do
fine grain
> checks
> via LSM.
>
>
> The main idea is to run eBPF RSS with qemu without any
permission.
> Libvirt should handle everything and pass proper eBPF file
descriptors.
> For current eBPF RSS, CAP_SYS_ADMIN(bypass some limitations)
> also required, and in the future may be other permissions.
I may miss something.
But RSS requires to update the map. This won't work if you
don't grant
any permission to qemu.
Thanks
>
> I'm not sure this is the best. We have several examples
that let
> libvirt
> to involve. Examples:
>
> 1) create TAP device (and the TUN_SETIFF)
>
> 2) open vhost devices
>
>
> Technically TAP/vhost not related to a particular qemu
emulator. So common
> TAP creation should fit any modern qemu. eBPF fds(program
and maps) should
> suit the interface for current qemu, g.e. some qemu builds
may have
> different map
> structures or their count. It's necessary that the qemu got fds
> prepared by the helper
> that was built with the qemu.
>
> I think we need an example on the detail steps for how
libvirt is
> expected to use this.
>
>
> The simplified workflow looks like this:
>
> 1. Libvirt got "emulator" from domain document.
> 2. Libvirt queries for qemu capabilities.
> 3. One of the capabilities is "qemu-ebpf-rss-helper"
path(if present).
> 4. On NIC preparation Libvirt checks for virtio-net + rss
configurations.
> 5. If required, the "qemu-ebpf-rss-helper" called and fds are
> received through unix fd.
> 6. Those fds are for eBPF RSS, which passed to child
process - qemu.
> 7. Qemu launched with virtio-net-pci property "rss" and
"ebpf_rss_fds".
>
>
> On Fri, Jun 11, 2021 at 8:36 AM Jason Wang
<jasow...@redhat.com <mailto:jasow...@redhat.com>
> <mailto:jasow...@redhat.com <mailto:jasow...@redhat.com>>>
wrote:
>
>
> 在 2021/6/10 下午2:55, Yuri Benditovich 写道:
> > On Thu, Jun 10, 2021 at 9:41 AM Jason
Wang<jasow...@redhat.com <mailto:jasow...@redhat.com>
> <mailto:jasow...@redhat.com
<mailto:jasow...@redhat.com>>> wrote:
> >> 在 2021/6/9 下午6:04, Andrew Melnychenko 写道:
> >>> Libvirt usually launches qemu with strict permissions.
> >>> To enable eBPF RSS steering, qemu-ebpf-rss-helper
was added.
> >> A silly question:
> >>
> >> Kernel had the following permission checks in bpf
syscall:
> >>
> >> if (sysctl_unprivileged_bpf_disabled &&
!bpf_capable())
> >> return -EPERM;
> >> ...
> >>
> >> err = security_bpf(cmd, &attr, size);
> >> if (err < 0)
> >> return err;
> >>
> >> So if I understand the code correctly, bpf syscall
can only be
> done if:
> >>
> >> 1) unprivileged_bpf is enabled or
> >> 2) has the capability and pass the LSM checks
> >>
> >> So I think the series is for unprivileged_bpf
disabled. If I'm not
> >> wrong, I guess the policy is to grant CAP_BPF but do
fine grain
> checks
> >> via LSM.
> >>
> >> If this is correct, need to describe it in the commit
log.
> >>
> >>
> >>> Added property "ebpf_rss_fds" for "virtio-net" that
allows to
> >>> initialize eBPF RSS context with passed program &
maps fds.
> >>>
> >>> Added qemu-ebpf-rss-helper - simple helper that
loads eBPF
> >>> context and passes fds through unix socket.
> >>> Libvirt should call the helper and pass fds to qemu
through
> >>> "ebpf_rss_fds" property.
> >>>
> >>> Added explicit target OS check for libbpf dependency
in meson.
> >>> eBPF RSS works only with Linux TAP, so there is no
reason to
> >>> build eBPF loader/helper for non-Linux.
> >>>
> >>> Overall, libvirt process should not be aware of the
"interface"
> >>> of eBPF RSS, it will not be aware of eBPF
maps/program "type" and
> >>> their quantity.
> >> I'm not sure this is the best. We have several
examples that
> let libvirt
> >> to involve. Examples:
> >>
> >> 1) create TAP device (and the TUN_SETIFF)
> >>
> >> 2) open vhost devices
> >>
> >>
> >>> That's why qemu and the helper should be from
> >>> the same build and be "synchronized". Technically
each qemu may
> >>> have its own helper. That's why "query-helper-paths"
qmp command
> >>> was added. Qemu should return the path to the helper
that suits
> >>> and libvirt should use "that" helper for "that"
emulator.
> >>>
> >>> qmp sample:
> >>> C: { "execute": "query-helper-paths" }
> >>> S: { "return": [
> >>> {
> >>> "name": "qemu-ebpf-rss-helper",
> >>> "path":
"/usr/local/libexec/qemu-ebpf-rss-helper"
> >>> }
> >>> ]
> >>> }
> >> I think we need an example on the detail steps for
how libvirt is
> >> expected to use this.
> > The preliminary patches for libvirt are at
> > https://github.com/daynix/libvirt/tree/RSSv1
<https://github.com/daynix/libvirt/tree/RSSv1>
> <https://github.com/daynix/libvirt/tree/RSSv1
<https://github.com/daynix/libvirt/tree/RSSv1>>
>
>
> Will have a look but it would be better if the
assumption of the
> management is detailed here to ease the reviewers.
>
> Thanks
>
>
> >
>
