Re: [PATCH v2] bpf: allow BPF_LOG_KERNEL from kernel space

[Alexei Starovoitov]

On Wed, Jun 24, 2026 at 11:19 AM Siddharth Nayyar <sidnayyar@xxxxxxxxxx> wrote:
>
> When loading a BPF program or BTF from kernel space (e.g. using a
> light skeleton generated loader module), the kernel module may want
> to output verifier logs to dmesg by setting attr->log_level =
> BPF_LOG_KERNEL (16).
>
> Currently, any attempt to do this through the standard syscall path
> (kern_sys_bpf -> bpf_vlog_init) fails with -EINVAL because
> bpf_verifier_log_attr_valid() rejects any log_level bit outside
> BPF_LOG_MASK. This prevents in-kernel loaders from successfully
> using BPF_LOG_KERNEL, causing silent failures if the BPF object
> is rejected by the verifier.
>
> This patch modifies bpf_verifier_log_attr_valid() to accept
> BPF_LOG_KERNEL unconditionally. To prevent userspace from exploiting
> this to spam the kernel log, the patch enforces a strict privilege
> check at the syscall boundary points (btf_parse, bpf_log_attr_init,
> bpf_log_attr_create_vlog), ensuring BPF_LOG_KERNEL is only permitted
> when uattr.is_kernel is true.

I don't think it's a good idea.
BPF_LOG_KERNEL prints to dmesg and it's there for cases
where BTF is corrupted in vmlinux or in the module.
The verifier log can be large. It's never suitable for dmesg.

Let's step back and discuss the end goal.
Not just this patch, but overall.
You're sending a bunch of patches for various lskel things.
Please explain the full picture.

pw-bot: cr