On Wed, 2022-09-07 at 16:57 +0200, Kumar Kartikeya Dwivedi wrote: > On Wed, 7 Sept 2022 at 16:49, Roberto Sassu > <roberto.sassu@xxxxxxxxxxxxxxx> wrote: > > On Tue, 2022-09-06 at 09:35 +0200, Roberto Sassu wrote: > > > On Mon, 2022-09-05 at 21:26 +0200, Kumar Kartikeya Dwivedi wrote: > > > > On Mon, 5 Sept 2022 at 16:34, Roberto Sassu > > > > <roberto.sassu@xxxxxxxxxxxxxxx> wrote: > > > > > From: Roberto Sassu <roberto.sassu@xxxxxxxxxx> > > > > > > > > > > One of the desirable features in security is the ability to > > > > > restrict import > > > > > of data to a given system based on data authenticity. If data > > > > > import can be > > > > > restricted, it would be possible to enforce a system-wide > > > > > policy > > > > > based on > > > > > the signing keys the system owner trusts. > > > > > > > > > > This feature is widely used in the kernel. For example, if > > > > > the > > > > > restriction > > > > > is enabled, kernel modules can be plugged in only if they are > > > > > signed with a > > > > > key whose public part is in the primary or secondary keyring. > > > > > > > > > > For eBPF, it can be useful as well. For example, it might be > > > > > useful > > > > > to > > > > > authenticate data an eBPF program makes security decisions > > > > > on. > > > > > > > > > > [...] > > > > > > > > CI is crashing with NULL deref for test_progs-no_alu32 with > > > > llvm- > > > > 16, > > > > but I don't think the problem is in this series. This is most > > > > likely > > > > unrelated to BPF, as the crash happens inside > > > > kernel/time/tick-sched.c:tick_nohz_restart_sched_tick. > > > > > > > > This was the same case in > > > > https://lore.kernel.org/bpf/CAP01T74steDfP6O8QOshoto3e3RnHhKtAeTbnrPBZS3YJXjvbA@xxxxxxxxxxxxxx. > > > > > > > > So, > > > > https://github.com/kernel-patches/bpf/runs/8194263557?check_suite_focus=true > > > > and > > > > https://github.com/kernel-patches/bpf/runs/7982907380?check_suite_focus=true > > > > > > > > look similar to me, and may not be related to BPF. They only > > > > trigger > > > > during runs compiled using LLVM 16, so maybe some compiler > > > > transformation is surfacing the problem? > > > > > > Yes, I saw that too. Not sure what the cause could be. > > > > > > > Another occurrence, this time with gcc: > > > > https://github.com/robertosassu/vmtest/runs/8230071814?check_suite_focus=true > > > > ... and it seems like this run does not even have your patches, > right? > Uhm, the kernel patches are there. The tests except the verifier ones weren't successfuly applied, probably due to the deny list. One thing in common with the failures seems when the panic happens, when test_progs reaches verif_twfw. I will try to execute this and earlier tests to reproduce the panic locally. Roberto
