Changes in Kconfig

2c9e5d4a - bpf: remove CONFIG_BPF_JIT dependency on CONFIG_MODULES of

Sun, 05 May 2024 16:06:28 +0000

bpf: remove CONFIG_BPF_JIT dependency on CONFIG_MODULES ofBPF just-in-time compiler depended on CONFIG_MODULES because it usedmodule_alloc() to allocate memory for the generated code.Since code allocations are now implemented with execmem, drop dependency ofCONFIG_BPF_JIT on CONFIG_MODULES and make it select CONFIG_EXECMEM.Suggested-by: Björn Töpel Signed-off-by: Mike Rapoport (IBM) Signed-off-by: Luis Chamberlain List of files: /linux-6.15/kernel/bpf/Kconfig

b993115b - bpf: Select new NEED_TASKS_RCU Kconfig option

Thu, 22 Feb 2024 18:16:17 +0000

bpf: Select new NEED_TASKS_RCU Kconfig optionCurrently, if a Kconfig option depends on TASKS_RCU, it conditionally does"select TASKS_RCU if PREEMPTION". This works, but requires any change inthis enablement logic to be replicated across all such "select" clauses.A new NEED_TASKS_RCU Kconfig option has been created to allow thisenablement logic to be in one place in kernel/rcu/Kconfig.Therefore, make BPF select the new NEED_TASKS_RCU Kconfig option.Signed-off-by: Paul E. McKenney Cc: Alexei Starovoitov Cc: Daniel Borkmann Cc: Andrii Nakryiko Cc: Martin KaFai Lau Cc: Song Liu Cc: Yonghong Song Cc: John Fastabend Cc: KP Singh Cc: Stanislav Fomichev Cc: Hao Luo Cc: Jiri Olsa Cc: Cc: Ankur Arora Cc: Thomas Gleixner Cc: Steven Rostedt Acked-by: Mark Rutland Signed-off-by: Uladzislau Rezki (Sony) List of files: /linux-6.15/kernel/bpf/Kconfig

e55dad12 - bpf: Merge two CONFIG_BPF entries

Sun, 04 Feb 2024 07:56:34 +0000

bpf: Merge two CONFIG_BPF entries'config BPF' exists in both init/Kconfig and kernel/bpf/Kconfig.Commit b24abcff918a ("bpf, kconfig: Add consolidated menu entry for bpfwith core options") added the second one to kernel/bpf/Kconfig insteadof moving the existing one.Merge them together.Signed-off-by: Masahiro Yamada Signed-off-by: Andrii Nakryiko Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20240204075634.32969-1-masahiroy@kernel.org List of files: /linux-6.15/kernel/bpf/Kconfig

e420bed0 - bpf: Add fd-based tcx multi-prog infra with link support

Wed, 19 Jul 2023 14:08:52 +0000

bpf: Add fd-based tcx multi-prog infra with link supportThis work refactors and adds a lightweight extension ("tcx") to the tc BPFingress and egress data path side for allowing BPF program management basedon fds via bpf() syscall through the newly added generic multi-prog API.The main goal behind this work which we also presented at LPC [0] last yearand a recent update at LSF/MM/BPF this year [3] is to support long-awaitedBPF link functionality for tc BPF programs, which allows for a model of safeownership and program detachment.Given the rise in tc BPF users in cloud native environments, this becomesnecessary to avoid hard to debug incidents either through stale leftoverprograms or 3rd party applications accidentally stepping on each others toes.As a recap, a BPF link represents the attachment of a BPF program to a BPFhook point. The BPF link holds a single reference to keep BPF program alive.Moreover, hook points do not reference a BPF link, only the application'sfd or pinning does. A BPF link holds meta-data specific to attachment andimplements operations for link creation, (atomic) BPF program update,detachment and introspection. The motivation for BPF links for tc BPF programsis multi-fold, for example: - From Meta: "It's especially important for applications that are deployed fleet-wide and that don't "control" hosts they are deployed to. If such application crashes and no one notices and does anything about that, BPF program will keep running draining resources or even just, say, dropping packets. We at FB had outages due to such permanent BPF attachment semantics. With fd-based BPF link we are getting a framework, which allows safe, auto-detachable behavior by default, unless application explicitly opts in by pinning the BPF link." [1] - From Cilium-side the tc BPF programs we attach to host-facing veth devices and phys devices build the core datapath for Kubernetes Pods, and they implement forwarding, load-balancing, policy, EDT-management, etc, within BPF. Currently there is no concept of 'safe' ownership, e.g. we've recently experienced hard-to-debug issues in a user's staging environment where another Kubernetes application using tc BPF attached to the same prio/handle of cls_bpf, accidentally wiping all Cilium-based BPF programs from underneath it. The goal is to establish a clear/safe ownership model via links which cannot accidentally be overridden. [0,2]BPF links for tc can co-exist with non-link attachments, and the semantics arein line also with XDP links: BPF links cannot replace other BPF links, BPFlinks cannot replace non-BPF links, non-BPF links cannot replace BPF links andlastly only non-BPF links can replace non-BPF links. In case of Cilium, thiswould solve mentioned issue of safe ownership model as 3rd party applicationswould not be able to accidentally wipe Cilium programs, even if they are notBPF link aware.Earlier attempts [4] have tried to integrate BPF links into core tc machineryto solve cls_bpf, which has been intrusive to the generic tc kernel API withextensions only specific to cls_bpf and suboptimal/complex since cls_bpf couldbe wiped from the qdisc also. Locking a tc BPF program in place this way, isgetting into layering hacks given the two object models are vastly different.We instead implemented the tcx (tc 'express') layer which is an fd-based tc BPFattach API, so that the BPF link implementation blends in naturally similar toother link types which are fd-based and without the need for changing core tcinternal APIs. BPF programs for tc can then be successively migrated from classiccls_bpf to the new tc BPF link without needing to change the program's sourcecode, just the BPF loader mechanics for attaching is sufficient.For the current tc framework, there is no change in behavior with this changeand neither does this change touch on tc core kernel APIs. The gist of thispatch is that the ingress and egress hook have a lightweight, qdisc-lessextension for BPF to attach its tc BPF programs, in other words, a minimalentry point for tc BPF. The name tcx has been suggested from discussion ofearlier revisions of this work as a good fit, and to more easily differ betweenthe classic cls_bpf attachment and the fd-based one.For the ingress and egress tcx points, the device holds a cache-friendly arraywith program pointers which is separated from control plane (slow-path) data.Earlier versions of this work used priority to determine ordering and expressionof dependencies similar as with classic tc, but it was challenged that forsomething more future-proof a better user experience is required. Hence thisresulted in the design and development of the generic attach/detach/query APIfor multi-progs. See prior patch with its discussion on the API design. tcx isthe first user and later we plan to integrate also others, for example, onecandidate is multi-prog support for XDP which would benefit and have the same'look and feel' from API perspective.The goal with tcx is to have maximum compatibility to existing tc BPF programs,so they don't need to be rewritten specifically. Compatibility to call intoclassic tcf_classify() is also provided in order to allow successive migrationor both to cleanly co-exist where needed given its all one logical tc layer andthe tcx plus classic tc cls/act build one logical overall processing pipeline.tcx supports the simplified return codes TCX_NEXT which is non-terminating (goto next program) and terminating ones with TCX_PASS, TCX_DROP, TCX_REDIRECT.The fd-based API is behind a static key, so that when unused the code is alsonot entered. The struct tcx_entry's program array is currently static, butcould be made dynamic if necessary at a point in future. The a/b pair swapdesign has been chosen so that for detachment there are no allocations whichotherwise could fail.The work has been tested with tc-testing selftest suite which all passes, aswell as the tc BPF tests from the BPF CI, and also with Cilium's L4LB.Thanks also to Nikolay Aleksandrov and Martin Lau for in-depth early reviewsof this work. [0] https://lpc.events/event/16/contributions/1353/ [1] https://lore.kernel.org/bpf/CAEf4BzbokCJN33Nw_kg82sO=xppXnKWEncGTWCTB9vGCmLB6pw@mail.gmail.com [2] https://colocatedeventseu2023.sched.com/event/1Jo6O/tales-from-an-ebpf-programs-murder-mystery-hemanth-malla-guillaume-fournier-datadog [3] http://vger.kernel.org/bpfconf2023_material/tcx_meta_netdev_borkmann.pdf [4] https://lore.kernel.org/bpf/20210604063116.234316-1-memxor@gmail.comSigned-off-by: Daniel Borkmann Acked-by: Jakub Kicinski Link: https://lore.kernel.org/r/20230719140858.13224-3-daniel@iogearbox.netSigned-off-by: Alexei Starovoitov List of files: /linux-6.15/kernel/bpf/Kconfig

835f14ed - rcu: Make the TASKS_RCU Kconfig option be selected

Thu, 17 Mar 2022 18:05:09 +0000

rcu: Make the TASKS_RCU Kconfig option be selectedCurrently, any kernel built with CONFIG_PREEMPTION=y also getsCONFIG_TASKS_RCU=y, which is not helpful to people trying to buildpreemptible kernels of minimal size.Because CONFIG_TASKS_RCU=y is needed only in kernels doing tracing ofone form or another, this commit moves from TASKS_RCU deciding when itshould be enabled to the tracing Kconfig options explicitly selecting it.This allows building preemptible kernels without TASKS_RCU, if desired.This commit also updates the SRCU-N and TREE09 rcutorture scenariosin order to avoid Kconfig errors that would otherwise result fromCONFIG_TASKS_RCU being selected without its CONFIG_RCU_EXPERT dependencybeing met.[ paulmck: Apply BPF_SYSCALL feedback from Andrii Nakryiko. ]Reported-by: Hyeonggon Yoo <42.hyeyoo@gmail.com>Tested-by: Hyeonggon Yoo <42.hyeyoo@gmail.com>Tested-by: Zhouyi Zhou Cc: Andrii Nakryiko Cc: Alexei Starovoitov Cc: Steven Rostedt Cc: Mathieu Desnoyers Acked-by: Masami Hiramatsu Signed-off-by: Paul E. McKenney List of files: /linux-6.15/kernel/bpf/Kconfig

b530e9e1 - bpf: Add "live packet" mode for XDP in BPF_PROG_RUN

Wed, 09 Mar 2022 10:53:42 +0000

bpf: Add "live packet" mode for XDP in BPF_PROG_RUNThis adds support for running XDP programs through BPF_PROG_RUN in a modethat enables live packet processing of the resulting frames. Previous usesof BPF_PROG_RUN for XDP returned the XDP program return code and themodified packet data to userspace, which is useful for unit testing of XDPprograms.The existing BPF_PROG_RUN for XDP allows userspace to set the ingressifindex and RXQ number as part of the context object being passed to thekernel. This patch reuses that code, but adds a new mode with differentsemantics, which can be selected with the new BPF_F_TEST_XDP_LIVE_FRAMESflag.When running BPF_PROG_RUN in this mode, the XDP program return codes willbe honoured: returning XDP_PASS will result in the frame being injectedinto the networking stack as if it came from the selected networkinginterface, while returning XDP_TX and XDP_REDIRECT will result in the framebeing transmitted out that interface. XDP_TX is translated into anXDP_REDIRECT operation to the same interface, since the real XDP_TX actionis only possible from within the network drivers themselves, not from theprocess context where BPF_PROG_RUN is executed.Internally, this new mode of operation creates a page pool instance whilesetting up the test run, and feeds pages from that into the XDP program.The setup cost of this is amortised over the number of repetitionsspecified by userspace.To support the performance testing use case, we further optimise the setupstep so that all pages in the pool are pre-initialised with the packetdata, and pre-computed context and xdp_frame objects stored at the start ofeach page. This makes it possible to entirely avoid touching the pagecontent on each XDP program invocation, and enables sending up to 9Mpps/core on my test box.Because the data pages are recycled by the page pool, and the test runnerdoesn't re-initialise them for each run, subsequent invocations of the XDPprogram will see the packet data in the state it was after the last time itran on that particular page. This means that an XDP program that modifiesthe packet before redirecting it has to be careful about which assumptionsit makes about the packet content, but that is only an issue for the mostnaively written programs.Enabling the new flag is only allowed when not setting ctx_out and data_outin the test specification, since using it means frames will be redirectedsomewhere else, so they can't be returned.Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Alexei Starovoitov Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20220309105346.100053-2-toke@redhat.com List of files: /linux-6.15/kernel/bpf/Kconfig

b664e255 - bpf: Add some description about BPF_JIT_ALWAYS_ON in Kconfig

Tue, 22 Feb 2022 09:57:05 +0000

bpf: Add some description about BPF_JIT_ALWAYS_ON in KconfigWhen CONFIG_BPF_JIT_ALWAYS_ON is enabled, /proc/sys/net/core/bpf_jit_enableis permanently set to 1 and setting any other value than that will returnfailure.Add the above description in the help text of config BPF_JIT_ALWAYS_ON, andthen we can distinguish between BPF_JIT_ALWAYS_ON and BPF_JIT_DEFAULT_ON.Signed-off-by: Tiezhu Yang Signed-off-by: Daniel Borkmann Acked-by: Song Liu Link: https://lore.kernel.org/bpf/1645523826-18149-2-git-send-email-yangtiezhu@loongson.cn List of files: /linux-6.15/kernel/bpf/Kconfig

8a03e56b - bpf: Disallow unprivileged bpf by default

Fri, 29 Oct 2021 19:43:54 +0000

bpf: Disallow unprivileged bpf by defaultDisabling unprivileged BPF would help prevent unprivileged users fromcreating certain conditions required for potential speculative executionside-channel attacks on unmitigated affected hardware.A deep dive on such attacks and current mitigations is available here [0].Sync with what many distros are currently applying already, and disableunprivileged BPF by default. An admin can enable this at runtime, ifnecessary, as described in 08389d888287 ("bpf: Add kconfig knob fordisabling unpriv bpf by default"). [0] "BPF and Spectre: Mitigating transient execution attacks", Daniel Borkmann, eBPF Summit '21 https://ebpf.io/summit-2021-slides/eBPF_Summit_2021-Keynote-Daniel_Borkmann-BPF_and_Spectre.pdfSigned-off-by: Pawan Gupta Signed-off-by: Daniel Borkmann Acked-by: Daniel Borkmann Acked-by: Mark Rutland Link: https://lore.kernel.org/bpf/0ace9ce3f97656d5f62d11093ad7ee81190c3c25.1635535215.git.pawan.kumar.gupta@linux.intel.com List of files: /linux-6.15/kernel/bpf/Kconfig

17edea21 - sock_map: Relax config dependency to CONFIG_NET

Sun, 04 Jul 2021 19:02:42 +0000

sock_map: Relax config dependency to CONFIG_NETCurrently sock_map still has Kconfig dependency on CONFIG_INET,but there is no actual functional dependency on it after weintroduce ->psock_update_sk_prot().We have to extend it to CONFIG_NET now as we are going tosupport AF_UNIX.Signed-off-by: Cong Wang Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20210704190252.11866-2-xiyou.wangcong@gmail.com List of files: /linux-6.15/kernel/bpf/Kconfig

6bdacdb4 - bpf: Fix BPF_JIT kconfig symbol dependency

Wed, 12 May 2021 18:57:14 +0000

bpf: Fix BPF_JIT kconfig symbol dependencyRandy reported a randconfig build error recently on i386: ld: arch/x86/net/bpf_jit_comp32.o: in function `do_jit': bpf_jit_comp32.c:(.text+0x28c9): undefined reference to `__bpf_call_base' ld: arch/x86/net/bpf_jit_comp32.o: in function `bpf_int_jit_compile': bpf_jit_comp32.c:(.text+0x3694): undefined reference to `bpf_jit_blind_constants' ld: bpf_jit_comp32.c:(.text+0x3719): undefined reference to `bpf_jit_binary_free' ld: bpf_jit_comp32.c:(.text+0x3745): undefined reference to `bpf_jit_binary_alloc' ld: bpf_jit_comp32.c:(.text+0x37d3): undefined reference to `bpf_jit_prog_release_other' [...]The cause was that b24abcff918a ("bpf, kconfig: Add consolidated menu entry forbpf with core options") moved BPF_JIT from net/Kconfig into kernel/bpf/Kconfigand previously BPF_JIT was guarded by a 'if NET'. However, there is no actualdependency on NET, it's just that menuconfig NET selects BPF. And the latter inturn causes kernel/bpf/core.o to be built which contains above symbols. Randy'srandconfig didn't have NET set, and BPF wasn't either, but BPF_JIT otoh was.Detangle this by making BPF_JIT depend on BPF instead. arm64 was the only archthat pulled in its JIT in net/ via obj-$(CONFIG_NET), all others unconditionallypull this dir in via obj-y. Do the same since CONFIG_NET guard there is reallyuseless as we compiled the JIT via obj-$(CONFIG_BPF_JIT) += bpf_jit_comp.o anyway.Fixes: b24abcff918a ("bpf, kconfig: Add consolidated menu entry for bpf with core options")Reported-by: Randy Dunlap Signed-off-by: Daniel Borkmann Acked-by: Randy Dunlap Tested-by: Randy Dunlap List of files: /linux-6.15/kernel/bpf/Kconfig

08389d88 - bpf: Add kconfig knob for disabling unpriv bpf by default

Tue, 11 May 2021 20:35:17 +0000

bpf: Add kconfig knob for disabling unpriv bpf by defaultAdd a kconfig knob which allows for unprivileged bpf to be disabled by default.If set, the knob sets /proc/sys/kernel/unprivileged_bpf_disabled to value of 2.This still allows a transition of 2 -> {0,1} through an admin. Similarly,this also still keeps 1 -> {1} behavior intact, so that once set to permanentlydisabled, it cannot be undone aside from a reboot.We've also added extra2 with max of 2 for the procfs handler, so that an adminstill has a chance to toggle between 0 <-> 2.Either way, as an additional alternative, applications can make use of CAP_BPFthat we added a while ago.Signed-off-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/74ec548079189e4e4dffaeb42b8987bb3c852eee.1620765074.git.daniel@iogearbox.net List of files: /linux-6.15/kernel/bpf/Kconfig

b24abcff - bpf, kconfig: Add consolidated menu entry for bpf with core options

Tue, 11 May 2021 20:35:16 +0000

bpf, kconfig: Add consolidated menu entry for bpf with core optionsRight now, all core BPF related options are scattered in different Kconfiglocations mainly due to historic reasons. Moving forward, lets add a propersubsystem entry under ... General setup ---> BPF subsystem --->... in order to have all knobs in a single location and thus ease BPF relatedconfiguration. Networking related bits such as sockmap are out of scope forthe general setup and therefore better suited to remain in net/Kconfig.Signed-off-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/f23f58765a4d59244ebd8037da7b6a6b2fb58446.1620765074.git.daniel@iogearbox.net List of files: /linux-6.15/kernel/bpf/Kconfig