|
From: | Andrew Melnichenko |
Subject: | Re: [RFC PATCH 0/5] ebpf: Added ebpf helper for libvirtd. |
Date: | Fri, 11 Jun 2021 19:49:21 +0300 |
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.
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
I think we need an example on the detail steps for how libvirt is
expected to use this.
在 2021/6/10 下午2:55, Yuri Benditovich 写道:
> On Thu, Jun 10, 2021 at 9:41 AM Jason Wang<jasowang@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
Will have a look but it would be better if the assumption of the
management is detailed here to ease the reviewers.
Thanks
>
[Prev in Thread] | Current Thread | [Next in Thread] |