From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C7660C2B9F4 for ; Tue, 22 Jun 2021 13:03:31 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 2FBB161361 for ; Tue, 22 Jun 2021 13:03:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2FBB161361 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=daynix.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:32866 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lvg3u-0003w7-9Z for qemu-devel@archiver.kernel.org; Tue, 22 Jun 2021 09:03:30 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44024) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lvg2Z-0002QD-A3 for qemu-devel@nongnu.org; Tue, 22 Jun 2021 09:02:07 -0400 Received: from mail-ot1-x336.google.com ([2607:f8b0:4864:20::336]:35576) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lvg2U-0004wj-TZ for qemu-devel@nongnu.org; Tue, 22 Jun 2021 09:02:07 -0400 Received: by mail-ot1-x336.google.com with SMTP id 7-20020a9d0d070000b0290439abcef697so21125869oti.2 for ; Tue, 22 Jun 2021 06:02:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=daynix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4cXfi5PMC6KlxLdghM3vWMF7VkRMBcsqo9hnvAikASs=; b=nTRlVqPLr3s1JWnCrm+yy4CMn3K2okhmpt0HkAAo9jb1EZucq9Io/BlUwKNhN1hRPk 7TyEohRqdDSco0s2V/gPvwFp69a5187AMAY+s3mo4S1k4dGnpUBif7/8h97EY61hfCOC O//wzUNp7lWlzJMkbJPCqLFqiV6qgntT320UCe0sIHAnBVff/bgTPVh5alTVUJ+No/B/ jSNQsVaHqbJcQVHnsWGDwHFZAtzgoqrMlzRRr2cz5Wbex3YM6HBY4qYN8suB+xKi5hgm WNPUWUmpT7AiqiQgOvXt9r7LXXhsqk0LLTl4pTdARlaeEZDV71wgPt8tr0HFJNd3eaSA eeaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4cXfi5PMC6KlxLdghM3vWMF7VkRMBcsqo9hnvAikASs=; b=B0xXUZiLI5PedHeiyk5Tr8xDoG3RWnHFGef2DqfANUxemLgE02Ovgztii5IOr+J/s+ x36WDR1lbz+rs6zw4Bh/xabeKCxuGq4doF3RIfXL4W+EzughGqbedw5aPSqtBLX2/hHQ 7Pp/PZLdPj5iUd8HS2iQ/jqHPZSBv1MUcg70nNt2uwEc73av7VANjudEbH+gH2JGLeFc f9RpOWit8fbVeNXuCw52nRUHIe6eXq3XtUjXb+V8RxyEok20Sd+HK5ZquLmBIlbTYkCn aIjSJUOL4OIxRJTBvTpkLHZbwxm4zuLpNNVLNhRWCjyt391yOYP66b/9Hh3VHJH2E+x9 AJDg== X-Gm-Message-State: AOAM530AKVpfxX13kVbhq4pV1EvLQQ4UBjlOM5B4IjNaq6UVgMBN9uR/ EHdsQgmnWTpU3zEclrvZttDWUj5PByqqNNJq4hN/0g== X-Google-Smtp-Source: ABdhPJxzM8SJ9dUaMjeGBw2cFOQtbf8WxxZ4dEqHL+vDGUPeZTC4kUjGleBudc2qfPupyjbym/gVUJf2aifVGGAtvY8= X-Received: by 2002:a05:6830:1d0:: with SMTP id r16mr3113743ota.116.1624366919501; Tue, 22 Jun 2021 06:01:59 -0700 (PDT) MIME-Version: 1.0 References: <3da88930-439c-1892-29b4-4977ddbb0b0a@redhat.com> <07a81543-c262-f153-6414-3d967dde02b2@redhat.com> <9157bf00-299f-993d-dd16-62f13e017a3f@redhat.com> <87o8byqpao.fsf@toke.dk> <87im26qn9q.fsf@toke.dk> In-Reply-To: <87im26qn9q.fsf@toke.dk> From: Andrew Melnichenko Date: Tue, 22 Jun 2021 16:01:48 +0300 Message-ID: Subject: Re: [RFC PATCH 0/5] ebpf: Added ebpf helper for libvirtd. To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Content-Type: multipart/alternative; boundary="00000000000038dae805c55a65dc" Received-SPF: none client-ip=2607:f8b0:4864:20::336; envelope-from=andrew@daynix.com; helo=mail-ot1-x336.google.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?= , "Michael S . Tsirkin" , Jason Wang , Markus Armbruster , qemu-devel@nongnu.org, Yuri Benditovich , Yan Vugenfirer , Eric Blake Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" --00000000000038dae805c55a65dc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=C3=B8iland-J=C3=B8rgensen wrote: > Daniel P. Berrang=C3=A9 writes: > > > On Tue, Jun 22, 2021 at 10:25:19AM +0200, Toke H=C3=B8iland-J=C3=B8rgen= sen wrote: > >> Jason Wang writes: > >> > >> > =E5=9C=A8 2021/6/22 =E4=B8=8A=E5=8D=8811:29, Yuri Benditovich =E5=86= =99=E9=81=93: > >> >> On Mon, Jun 21, 2021 at 12:20 PM Jason Wang > wrote: > >> >>> > >> >>> =E5=9C=A8 2021/6/19 =E4=B8=8A=E5=8D=884:03, Andrew Melnichenko =E5= =86=99=E9=81=93: > >> >>>> Hi Jason, > >> >>>> I've checked "kernel.unprivileged_bpf_disabled=3D0" 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 ye= t > >> >> (for BPF we need 5.8+). > >> >> So this will be (probably) relevant for RHEL 9. Please correct me i= f > 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 > > --00000000000038dae805c55a65dc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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=C3=B8iland-J=C3=B8rgensen &= lt;toke@redhat.com> wrote:
Daniel P. Berrang=C3= =A9 <berrange@r= edhat.com> writes:

> On Tue, Jun 22, 2021 at 10:25:19AM +0200, Toke H=C3=B8iland-J=C3=B8rge= nsen wrote:
>> Jason Wang <jasowang@redhat.com> writes:
>>
>> > =E5=9C=A8 2021/6/22 =E4=B8=8A=E5=8D=8811:29, Yuri Benditovich= =E5=86=99=E9=81=93:
>> >> On Mon, Jun 21, 2021 at 12:20 PM Jason Wang <jasowang@redhat.com&g= t; wrote:
>> >>>
>> >>> =E5=9C=A8 2021/6/19 =E4=B8=8A=E5=8D=884:03, Andrew Me= lnichenko =E5=86=99=E9=81=93:
>> >>>> Hi Jason,
>> >>>> I've checked "kernel.unprivileged_bpf_di= sabled=3D0" on Fedora,=C2=A0 Ubuntu,
>> >>>> and Debian - no need permissions to update BPF ma= ps.
>> >>>
>> >>> How about RHEL :) ?
>> >> If I'm not mistaken, the RHEL releases do not use mod= ern kernels yet
>> >> (for BPF we need 5.8+).
>> >> So this will be (probably) relevant for RHEL 9. Please co= rrect me if I'm wrong.
>> >
>> > Adding Toke for more ideas on this.
>>
>> Ignore the kernel version number; we backport all of BPF to RHEL,<= br> >> basically. RHEL8.4 is up to upstream kernel 5.10, feature-wise. >>
>> However, we completely disable unprivileged BPF on RHEL kernels. A= lso,
>> 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_disa= ble 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= 9;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<= br> > 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 stil= l
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 wo= rk
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

--00000000000038dae805c55a65dc--