From: Roberto Sassu <roberto.sassu@huawei.com> To: <corbet@lwn.net>, <viro@zeniv.linux.org.uk>, <ast@kernel.org>, <daniel@iogearbox.net>, <andrii@kernel.org>, <kpsingh@kernel.org>, <shuah@kernel.org>, <mcoquelin.stm32@gmail.com>, <alexandre.torgue@foss.st.com>, <zohar@linux.ibm.com> Cc: <linux-doc@vger.kernel.org>, <linux-fsdevel@vger.kernel.org>, <netdev@vger.kernel.org>, <bpf@vger.kernel.org>, <linux-kselftest@vger.kernel.org>, <linux-stm32@st-md-mailman.stormreply.com>, <linux-arm-kernel@lists.infradead.org>, <linux-integrity@vger.kernel.org>, <linux-security-module@vger.kernel.org>, <linux-kernel@vger.kernel.org>, Roberto Sassu <roberto.sassu@huawei.com> Subject: [PATCH 00/18] bpf: Secure and authenticated preloading of eBPF programs Date: Mon, 28 Mar 2022 19:50:15 +0200 [thread overview] Message-ID: <20220328175033.2437312-1-roberto.sassu@huawei.com> (raw) eBPF already allows programs to be preloaded and kept running without intervention from user space. There is a dedicated kernel module called bpf_preload, which contains the light skeleton of the iterators_bpf eBPF program. If this module is enabled in the kernel configuration, its loading will be triggered when the bpf filesystem is mounted (unless the module is built-in), and the links of iterators_bpf are pinned in that filesystem (they will appear as the progs.debug and maps.debug files). However, the current mechanism, if used to preload an LSM, would not offer the same security guarantees of LSMs integrated in the security subsystem. Also, it is not generic enough to be used for preloading arbitrary eBPF programs, unless the bpf_preload code is heavily modified. More specifically, the security problems are: - any program can be pinned to the bpf filesystem without limitations (unless a MAC mechanism enforces some restrictions); - programs being executed can be terminated at any time by deleting the pinned objects or unmounting the bpf filesystem. The usability problems are: - only a fixed amount of links can be pinned; - only links can be pinned, other object types are not supported; - code to pin objects has to be written manually; - preloading multiple eBPF programs is not practical, bpf_preload has to be modified to include additional light skeletons. Solve the security problems by mounting the bpf filesystem from the kernel, by preloading authenticated kernel modules (e.g. with module.sig_enforce) and by pinning objects to that filesystem. This particular filesystem instance guarantees that desired eBPF programs run until the very end of the kernel lifecycle, since even root cannot interfere with it. Solve the usability problems by generalizing the pinning function, to handle not only links but also maps and progs. Also increment the object reference count and call the pinning function directly from the preload method (currently in the bpf_preload kernel module) rather than from the bpf filesystem code itself, so that a generic eBPF program can do those operations depending on its objects (this also avoids the limitation of the fixed-size array for storing the objects to pin). Then, simplify the process of pinning objects defined by a generic eBPF program by automatically generating the required methods in the light skeleton. Also, generate a separate kernel module for each eBPF program to preload, so that existing ones don't have to be modified. Finally, support preloading multiple eBPF programs by allowing users to specify a list from the kernel configuration, at build time, or with the new kernel option bpf_preload_list=, at run-time. To summarize, this patch set makes it possible to plug in out-of-tree LSMs matching the security guarantees of their counterpart in the security subsystem, without having to modify the kernel itself. The same benefits are extended to other eBPF program types. Only one remaining problem is how to support auto-attaching eBPF programs with LSM type. It will be solved with a separate patch set. Patches 1-2 export some definitions, to build out-of-tree kernel modules with eBPF programs to preload. Patches 3-4 allow eBPF programs to pin objects by themselves. Patches 5-10 automatically generate the methods for preloading in the light skeleton. Patches 11-14 make it possible to preload multiple eBPF programs. Patch 15 automatically generates the kernel module for preloading an eBPF program, patch 16 does a kernel mount of the bpf filesystem, and finally patches 17-18 test the functionality introduced. Roberto Sassu (18): bpf: Export bpf_link_inc() bpf-preload: Move bpf_preload.h to include/linux bpf-preload: Generalize object pinning from the kernel bpf-preload: Export and call bpf_obj_do_pin_kernel() bpf-preload: Generate static variables bpf-preload: Generate free_objs_and_skel() bpf-preload: Generate preload() bpf-preload: Generate load_skel() bpf-preload: Generate code to pin non-internal maps bpf-preload: Generate bpf_preload_ops bpf-preload: Store multiple bpf_preload_ops structures in a linked list bpf-preload: Implement new registration method for preloading eBPF programs bpf-preload: Move pinned links and maps to a dedicated directory in bpffs bpf-preload: Switch to new preload registration method bpf-preload: Generate code of kernel module to preload bpf-preload: Do kernel mount to ensure that pinned objects don't disappear bpf-preload/selftests: Add test for automatic generation of preload methods bpf-preload/selftests: Preload a test eBPF program and check pinned objects .../admin-guide/kernel-parameters.txt | 8 + fs/namespace.c | 1 + include/linux/bpf.h | 5 + include/linux/bpf_preload.h | 37 ++ init/main.c | 2 + kernel/bpf/inode.c | 295 +++++++++-- kernel/bpf/preload/Kconfig | 25 +- kernel/bpf/preload/bpf_preload.h | 16 - kernel/bpf/preload/bpf_preload_kern.c | 85 +--- kernel/bpf/preload/iterators/Makefile | 9 +- .../bpf/preload/iterators/iterators.lskel.h | 466 +++++++++++------- kernel/bpf/syscall.c | 1 + .../bpf/bpftool/Documentation/bpftool-gen.rst | 13 + tools/bpf/bpftool/bash-completion/bpftool | 6 +- tools/bpf/bpftool/gen.c | 331 +++++++++++++ tools/bpf/bpftool/main.c | 7 +- tools/bpf/bpftool/main.h | 1 + tools/testing/selftests/bpf/Makefile | 32 +- .../bpf/bpf_testmod_preload/.gitignore | 7 + .../bpf/bpf_testmod_preload/Makefile | 20 + .../gen_preload_methods.expected.diff | 97 ++++ .../bpf/prog_tests/test_gen_preload_methods.c | 27 + .../bpf/prog_tests/test_preload_methods.c | 69 +++ .../selftests/bpf/progs/gen_preload_methods.c | 23 + 24 files changed, 1246 insertions(+), 337 deletions(-) create mode 100644 include/linux/bpf_preload.h delete mode 100644 kernel/bpf/preload/bpf_preload.h create mode 100644 tools/testing/selftests/bpf/bpf_testmod_preload/.gitignore create mode 100644 tools/testing/selftests/bpf/bpf_testmod_preload/Makefile create mode 100644 tools/testing/selftests/bpf/prog_tests/gen_preload_methods.expected.diff create mode 100644 tools/testing/selftests/bpf/prog_tests/test_gen_preload_methods.c create mode 100644 tools/testing/selftests/bpf/prog_tests/test_preload_methods.c create mode 100644 tools/testing/selftests/bpf/progs/gen_preload_methods.c -- 2.32.0
WARNING: multiple messages have this Message-ID (diff)
From: Roberto Sassu <roberto.sassu@huawei.com> To: <corbet@lwn.net>, <viro@zeniv.linux.org.uk>, <ast@kernel.org>, <daniel@iogearbox.net>, <andrii@kernel.org>, <kpsingh@kernel.org>, <shuah@kernel.org>, <mcoquelin.stm32@gmail.com>, <alexandre.torgue@foss.st.com>, <zohar@linux.ibm.com> Cc: <linux-doc@vger.kernel.org>, <linux-fsdevel@vger.kernel.org>, <netdev@vger.kernel.org>, <bpf@vger.kernel.org>, <linux-kselftest@vger.kernel.org>, <linux-stm32@st-md-mailman.stormreply.com>, <linux-arm-kernel@lists.infradead.org>, <linux-integrity@vger.kernel.org>, <linux-security-module@vger.kernel.org>, <linux-kernel@vger.kernel.org>, Roberto Sassu <roberto.sassu@huawei.com> Subject: [PATCH 00/18] bpf: Secure and authenticated preloading of eBPF programs Date: Mon, 28 Mar 2022 19:50:15 +0200 [thread overview] Message-ID: <20220328175033.2437312-1-roberto.sassu@huawei.com> (raw) eBPF already allows programs to be preloaded and kept running without intervention from user space. There is a dedicated kernel module called bpf_preload, which contains the light skeleton of the iterators_bpf eBPF program. If this module is enabled in the kernel configuration, its loading will be triggered when the bpf filesystem is mounted (unless the module is built-in), and the links of iterators_bpf are pinned in that filesystem (they will appear as the progs.debug and maps.debug files). However, the current mechanism, if used to preload an LSM, would not offer the same security guarantees of LSMs integrated in the security subsystem. Also, it is not generic enough to be used for preloading arbitrary eBPF programs, unless the bpf_preload code is heavily modified. More specifically, the security problems are: - any program can be pinned to the bpf filesystem without limitations (unless a MAC mechanism enforces some restrictions); - programs being executed can be terminated at any time by deleting the pinned objects or unmounting the bpf filesystem. The usability problems are: - only a fixed amount of links can be pinned; - only links can be pinned, other object types are not supported; - code to pin objects has to be written manually; - preloading multiple eBPF programs is not practical, bpf_preload has to be modified to include additional light skeletons. Solve the security problems by mounting the bpf filesystem from the kernel, by preloading authenticated kernel modules (e.g. with module.sig_enforce) and by pinning objects to that filesystem. This particular filesystem instance guarantees that desired eBPF programs run until the very end of the kernel lifecycle, since even root cannot interfere with it. Solve the usability problems by generalizing the pinning function, to handle not only links but also maps and progs. Also increment the object reference count and call the pinning function directly from the preload method (currently in the bpf_preload kernel module) rather than from the bpf filesystem code itself, so that a generic eBPF program can do those operations depending on its objects (this also avoids the limitation of the fixed-size array for storing the objects to pin). Then, simplify the process of pinning objects defined by a generic eBPF program by automatically generating the required methods in the light skeleton. Also, generate a separate kernel module for each eBPF program to preload, so that existing ones don't have to be modified. Finally, support preloading multiple eBPF programs by allowing users to specify a list from the kernel configuration, at build time, or with the new kernel option bpf_preload_list=, at run-time. To summarize, this patch set makes it possible to plug in out-of-tree LSMs matching the security guarantees of their counterpart in the security subsystem, without having to modify the kernel itself. The same benefits are extended to other eBPF program types. Only one remaining problem is how to support auto-attaching eBPF programs with LSM type. It will be solved with a separate patch set. Patches 1-2 export some definitions, to build out-of-tree kernel modules with eBPF programs to preload. Patches 3-4 allow eBPF programs to pin objects by themselves. Patches 5-10 automatically generate the methods for preloading in the light skeleton. Patches 11-14 make it possible to preload multiple eBPF programs. Patch 15 automatically generates the kernel module for preloading an eBPF program, patch 16 does a kernel mount of the bpf filesystem, and finally patches 17-18 test the functionality introduced. Roberto Sassu (18): bpf: Export bpf_link_inc() bpf-preload: Move bpf_preload.h to include/linux bpf-preload: Generalize object pinning from the kernel bpf-preload: Export and call bpf_obj_do_pin_kernel() bpf-preload: Generate static variables bpf-preload: Generate free_objs_and_skel() bpf-preload: Generate preload() bpf-preload: Generate load_skel() bpf-preload: Generate code to pin non-internal maps bpf-preload: Generate bpf_preload_ops bpf-preload: Store multiple bpf_preload_ops structures in a linked list bpf-preload: Implement new registration method for preloading eBPF programs bpf-preload: Move pinned links and maps to a dedicated directory in bpffs bpf-preload: Switch to new preload registration method bpf-preload: Generate code of kernel module to preload bpf-preload: Do kernel mount to ensure that pinned objects don't disappear bpf-preload/selftests: Add test for automatic generation of preload methods bpf-preload/selftests: Preload a test eBPF program and check pinned objects .../admin-guide/kernel-parameters.txt | 8 + fs/namespace.c | 1 + include/linux/bpf.h | 5 + include/linux/bpf_preload.h | 37 ++ init/main.c | 2 + kernel/bpf/inode.c | 295 +++++++++-- kernel/bpf/preload/Kconfig | 25 +- kernel/bpf/preload/bpf_preload.h | 16 - kernel/bpf/preload/bpf_preload_kern.c | 85 +--- kernel/bpf/preload/iterators/Makefile | 9 +- .../bpf/preload/iterators/iterators.lskel.h | 466 +++++++++++------- kernel/bpf/syscall.c | 1 + .../bpf/bpftool/Documentation/bpftool-gen.rst | 13 + tools/bpf/bpftool/bash-completion/bpftool | 6 +- tools/bpf/bpftool/gen.c | 331 +++++++++++++ tools/bpf/bpftool/main.c | 7 +- tools/bpf/bpftool/main.h | 1 + tools/testing/selftests/bpf/Makefile | 32 +- .../bpf/bpf_testmod_preload/.gitignore | 7 + .../bpf/bpf_testmod_preload/Makefile | 20 + .../gen_preload_methods.expected.diff | 97 ++++ .../bpf/prog_tests/test_gen_preload_methods.c | 27 + .../bpf/prog_tests/test_preload_methods.c | 69 +++ .../selftests/bpf/progs/gen_preload_methods.c | 23 + 24 files changed, 1246 insertions(+), 337 deletions(-) create mode 100644 include/linux/bpf_preload.h delete mode 100644 kernel/bpf/preload/bpf_preload.h create mode 100644 tools/testing/selftests/bpf/bpf_testmod_preload/.gitignore create mode 100644 tools/testing/selftests/bpf/bpf_testmod_preload/Makefile create mode 100644 tools/testing/selftests/bpf/prog_tests/gen_preload_methods.expected.diff create mode 100644 tools/testing/selftests/bpf/prog_tests/test_gen_preload_methods.c create mode 100644 tools/testing/selftests/bpf/prog_tests/test_preload_methods.c create mode 100644 tools/testing/selftests/bpf/progs/gen_preload_methods.c -- 2.32.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next reply other threads:[~2022-03-28 17:52 UTC|newest] Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-03-28 17:50 Roberto Sassu [this message] 2022-03-28 17:50 ` [PATCH 00/18] bpf: Secure and authenticated preloading of eBPF programs Roberto Sassu 2022-03-28 17:50 ` [PATCH 01/18] bpf: Export bpf_link_inc() Roberto Sassu 2022-03-28 17:50 ` Roberto Sassu 2022-03-28 17:50 ` [PATCH 02/18] bpf-preload: Move bpf_preload.h to include/linux Roberto Sassu 2022-03-28 17:50 ` Roberto Sassu 2022-03-28 17:50 ` [PATCH 03/18] bpf-preload: Generalize object pinning from the kernel Roberto Sassu 2022-03-28 17:50 ` Roberto Sassu 2022-03-28 17:50 ` [PATCH 04/18] bpf-preload: Export and call bpf_obj_do_pin_kernel() Roberto Sassu 2022-03-28 17:50 ` Roberto Sassu 2022-03-28 17:50 ` [PATCH 05/18] bpf-preload: Generate static variables Roberto Sassu 2022-03-28 17:50 ` Roberto Sassu 2022-03-29 23:51 ` Andrii Nakryiko 2022-03-29 23:51 ` Andrii Nakryiko 2022-03-30 7:44 ` Roberto Sassu 2022-03-30 7:44 ` Roberto Sassu 2022-04-04 0:22 ` Andrii Nakryiko 2022-04-04 0:22 ` Andrii Nakryiko 2022-03-30 15:12 ` Roberto Sassu 2022-03-30 15:12 ` Roberto Sassu 2022-03-28 17:50 ` [PATCH 06/18] bpf-preload: Generate free_objs_and_skel() Roberto Sassu 2022-03-28 17:50 ` Roberto Sassu 2022-03-28 17:50 ` [PATCH 07/18] bpf-preload: Generate preload() Roberto Sassu 2022-03-28 17:50 ` Roberto Sassu 2022-03-28 17:50 ` [PATCH 08/18] bpf-preload: Generate load_skel() Roberto Sassu 2022-03-28 17:50 ` Roberto Sassu 2022-03-28 17:50 ` [PATCH 09/18] bpf-preload: Generate code to pin non-internal maps Roberto Sassu 2022-03-28 17:50 ` Roberto Sassu 2022-03-28 17:50 ` [PATCH 10/18] bpf-preload: Generate bpf_preload_ops Roberto Sassu 2022-03-28 17:50 ` Roberto Sassu 2022-03-28 17:50 ` [PATCH 11/18] bpf-preload: Store multiple bpf_preload_ops structures in a linked list Roberto Sassu 2022-03-28 17:50 ` Roberto Sassu 2022-03-28 17:50 ` [PATCH 12/18] bpf-preload: Implement new registration method for preloading eBPF programs Roberto Sassu 2022-03-28 17:50 ` Roberto Sassu 2022-03-28 17:50 ` [PATCH 13/18] bpf-preload: Move pinned links and maps to a dedicated directory in bpffs Roberto Sassu 2022-03-28 17:50 ` Roberto Sassu 2022-03-28 17:50 ` [PATCH 14/18] bpf-preload: Switch to new preload registration method Roberto Sassu 2022-03-28 17:50 ` Roberto Sassu 2022-03-29 2:35 ` kernel test robot 2022-03-29 2:35 ` kernel test robot 2022-03-29 3:27 ` kernel test robot 2022-03-29 3:27 ` kernel test robot 2022-03-28 17:50 ` [PATCH 15/18] bpf-preload: Generate code of kernel module to preload Roberto Sassu 2022-03-28 17:50 ` Roberto Sassu 2022-03-28 17:50 ` [PATCH 16/18] bpf-preload: Do kernel mount to ensure that pinned objects don't disappear Roberto Sassu 2022-03-28 17:50 ` Roberto Sassu 2022-03-29 2:15 ` kernel test robot 2022-03-29 2:15 ` kernel test robot 2022-03-29 4:08 ` kernel test robot 2022-03-29 4:08 ` kernel test robot 2022-03-28 17:50 ` [PATCH 17/18] bpf-preload/selftests: Add test for automatic generation of preload methods Roberto Sassu 2022-03-28 17:50 ` Roberto Sassu 2022-03-28 17:50 ` [PATCH 18/18] bpf-preload/selftests: Preload a test eBPF program and check pinned objects Roberto Sassu 2022-03-28 17:50 ` Roberto Sassu 2022-03-29 23:51 ` [PATCH 00/18] bpf: Secure and authenticated preloading of eBPF programs Andrii Nakryiko 2022-03-29 23:51 ` Andrii Nakryiko 2022-03-30 7:21 ` Roberto Sassu 2022-03-30 7:21 ` Roberto Sassu 2022-03-31 2:27 ` Alexei Starovoitov 2022-03-31 2:27 ` Alexei Starovoitov 2022-03-31 8:25 ` Roberto Sassu 2022-03-31 8:25 ` Roberto Sassu 2022-04-01 23:55 ` Alexei Starovoitov 2022-04-01 23:55 ` Alexei Starovoitov 2022-04-02 1:03 ` KP Singh 2022-04-02 1:03 ` KP Singh 2022-04-04 7:44 ` Djalal Harouni 2022-04-04 7:44 ` Djalal Harouni 2022-04-04 17:20 ` Roberto Sassu 2022-04-04 17:20 ` Roberto Sassu 2022-04-04 22:49 ` Alexei Starovoitov 2022-04-04 22:49 ` Alexei Starovoitov 2022-04-05 0:00 ` KP Singh 2022-04-05 0:00 ` KP Singh 2022-04-05 13:11 ` [POC][USER SPACE][PATCH] Introduce LSM to protect pinned objects Roberto Sassu 2022-04-05 13:11 ` Roberto Sassu 2022-04-05 22:47 ` Casey Schaufler 2022-04-05 22:47 ` Casey Schaufler 2022-04-06 6:55 ` Roberto Sassu 2022-04-06 6:55 ` Roberto Sassu 2022-04-05 14:49 ` [PATCH 00/18] bpf: Secure and authenticated preloading of eBPF programs Casey Schaufler 2022-04-05 14:49 ` Casey Schaufler 2022-04-05 15:29 ` Roberto Sassu 2022-04-05 15:29 ` Roberto Sassu 2022-04-05 16:21 ` Casey Schaufler 2022-04-05 16:21 ` Casey Schaufler 2022-04-05 16:37 ` KP Singh 2022-04-05 16:37 ` KP Singh 2022-04-04 17:41 ` Roberto Sassu 2022-04-04 17:41 ` Roberto Sassu
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20220328175033.2437312-1-roberto.sassu@huawei.com \ --to=roberto.sassu@huawei.com \ --cc=alexandre.torgue@foss.st.com \ --cc=andrii@kernel.org \ --cc=ast@kernel.org \ --cc=bpf@vger.kernel.org \ --cc=corbet@lwn.net \ --cc=daniel@iogearbox.net \ --cc=kpsingh@kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-doc@vger.kernel.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-integrity@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-kselftest@vger.kernel.org \ --cc=linux-security-module@vger.kernel.org \ --cc=linux-stm32@st-md-mailman.stormreply.com \ --cc=mcoquelin.stm32@gmail.com \ --cc=netdev@vger.kernel.org \ --cc=shuah@kernel.org \ --cc=viro@zeniv.linux.org.uk \ --cc=zohar@linux.ibm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.