linux-kernel - Re: [PATCH v3 0/4] Introducing Hornet LSM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACYkzJ5jsWFiXMRDwoGib5t+Xje6STTuJGRZM9Vg2dFz7uPa-g@mail.gmail.com>
Date: Mon, 5 May 2025 01:25:41 +0200
From: KP Singh <kpsingh@...nel.org>
To: Paul Moore <paul@...l-moore.com>
Cc: bboscaccy@...ux.microsoft.com, James.Bottomley@...senpartnership.com, 
	bpf@...r.kernel.org, code@...icks.com, corbet@....net, davem@...emloft.net, 
	dhowells@...hat.com, gnoack@...gle.com, herbert@...dor.apana.org.au, 
	jarkko@...nel.org, jmorris@...ei.org, jstancek@...hat.com, 
	justinstitt@...gle.com, keyrings@...r.kernel.org, 
	linux-crypto@...r.kernel.org, linux-doc@...r.kernel.org, 
	linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-kselftest@...r.kernel.org, linux-security-module@...r.kernel.org, 
	llvm@...ts.linux.dev, masahiroy@...nel.org, mic@...ikod.net, morbo@...gle.com, 
	nathan@...nel.org, neal@...pa.dev, nick.desaulniers+lkml@...il.com, 
	nicolas@...sle.eu, nkapron@...gle.com, roberto.sassu@...wei.com, 
	serge@...lyn.com, shuah@...nel.org, teknoraver@...a.com, 
	xiyou.wangcong@...il.com
Subject: Re: [PATCH v3 0/4] Introducing Hornet LSM

On Sun, May 4, 2025 at 7:36 PM Paul Moore <paul@...l-moore.com> wrote:
>
> On Fri, May 2, 2025 at 5:00 PM KP Singh <kpsingh@...nel.org> wrote:
> >
> > > This patch series introduces the Hornet LSM. The goal of Hornet is to provide
> > > a signature verification mechanism for eBPF programs.
> > >
> >
> > [...]
> >
> > >
> > > References: [1]
> > > https://lore.kernel.org/bpf/20220209054315.73833-1-alexei.starovoitov@gmail.com/
> > > [2]
> > > https://lore.kernel.org/bpf/CAADnVQ+wPK1KKZhCgb-Nnf0Xfjk8M1UpX5fnXC=cBzdEYbv_kg@mail.gmail.com/
> > >
> > > Change list: - v2 -> v3 - Remove any and all usage of proprietary bpf APIs
> >
> > BPF APIs are not proprietary, but you cannot implement BPF program signing
> > for BPF users without aligning with the BPF maintainers and the community.
> > Signed programs are a UAPI and a key part of how developers experience BPF
> > and this is not how we would like signing to be experienced by BPF users.
> >
> > Some more feedback (which should be pretty obvious) but explicitly:
> >
> > * Hacks like if (current->pid == 1) return 0; also break your threat model
> >   about root being untrusted.
>
> Speaking with Blaise off-list when that change was discussed, I
> believe the intent behind that Kconfig option was simply for
> development/transition purposes, and not for any long term usage.  My
> understanding is that this is why it was a separate build time
> configuration and not something that could be toggled at runtime, e.g.
> sysctl or similar.
>
> > * You also did not take the feedback into account:
> >
> >    new = map->ops->map_lookup_elem(map, &key);
> >
> >   This is not okay without having the BPF maintainers aligned, the same way as

[...]

>
> From what I've seen in Blaise's efforts to implement BPF signature
> validation in the upstream kernel he has been working in good faith
> and has been trying to work with the greater BPF community at each
> step along the way.  He attempted to learn from previously rejected
> attempts with his first patchset, however, that too was rejected, but
> with feedback on how he might proceed.  Blaise took that feedback and
> implemented Hornet, traveling to LSFMMBPF to present his idea to the
> BPF community, as well as the usual mailing list postings.  When there
> was feedback that certain APIs would not be permitted, despite being
> EXPORT_SYMBOL'd, Blaise made some adjustments and came back to the
> lists with an updated version.  You are obviously free to object to
> portions of Hornet, but I don't believe you can claim Blaise isn't
> trying to work with the BPF community on this effort.

Calling map->ops->map_lookup_elem wax objected to by Alexei.
This feedback was not incorporated.

>
> > So for this approach, it's a:
> >
> > Nacked-by: KP Singh <kpsingh@...nel.org>
>
> Noted.
>
> > Now if you really care about the use-case and want to work with the maintainers
> > and implement signing for the community, here's how we think it should be done:
> >
> > * The core signing logic and the tooling stays in BPF, something that the users
> >   are already using. No new tooling.
>
> I think we need a more detailed explanation of this approach on-list.
> There has been a lot of vague guidance on BPF signature validation
> from the BPF community which I believe has partly led us into the
> situation we are in now.  If you are going to require yet another
> approach, I think we all need to see a few paragraphs on-list
> outlining the basic design.

Definitely, happy to share design / code.



- KP

>
> > * The policy decision on the effect of signing can be built into various
> >   existing LSMs. I don't think we need a new LSM for it.
> > * A simple UAPI (emphasis on UAPI!) change to union bpf_attr in uapi/bpf.h in
> >   the BPF_PROG_LOAD command:
> >
> > __aligned_u64 signature;
> > __u32 signature_size;
>
> --
> paul-moore.com