[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z-wLKhlfJ5EQqvJC@kernel.org>
Date: Tue, 1 Apr 2025 18:50:02 +0300
From: Jarkko Sakkinen <jarkko@...nel.org>
To: Blaise Boscaccy <bboscaccy@...ux.microsoft.com>
Cc: Jonathan Corbet <corbet@....net>, David Howells <dhowells@...hat.com>,
Herbert Xu <herbert@...dor.apana.org.au>,
"David S. Miller" <davem@...emloft.net>,
Paul Moore <paul@...l-moore.com>, James Morris <jmorris@...ei.org>,
"Serge E. Hallyn" <serge@...lyn.com>,
Masahiro Yamada <masahiroy@...nel.org>,
Nathan Chancellor <nathan@...nel.org>,
Nicolas Schier <nicolas@...sle.eu>, Shuah Khan <shuah@...nel.org>,
Mickaël Salaün <mic@...ikod.net>,
Günther Noack <gnoack@...gle.com>,
Nick Desaulniers <nick.desaulniers+lkml@...il.com>,
Bill Wendling <morbo@...gle.com>,
Justin Stitt <justinstitt@...gle.com>,
Jan Stancek <jstancek@...hat.com>, Neal Gompa <neal@...pa.dev>,
linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
keyrings@...r.kernel.org, linux-crypto@...r.kernel.org,
linux-security-module@...r.kernel.org, linux-kbuild@...r.kernel.org,
linux-kselftest@...r.kernel.org, bpf@...r.kernel.org,
llvm@...ts.linux.dev, nkapron@...gle.com, teknoraver@...a.com,
roberto.sassu@...wei.com, xiyou.wangcong@...il.com
Subject: Re: [RFC PATCH security-next 0/4] Introducing Hornet LSM
On Mon, Mar 31, 2025 at 01:57:15PM -0700, Blaise Boscaccy wrote:
> There are two flavors of skeletons, normal skeletons, and light
> skeletons. Normal skeletons utilize relocation logic that lives in
> libbpf, and the relocations/instruction rewriting happen in userspace.
> The second flavor, light skeletons, uses a small eBPF program that
> contains the relocation lookup logic. As it's running in in the kernel,
> it unpacks the target program, peforms the instruction rewriting, and
> loads the target program. Light skeletons are currently utilized for
> some drivers, and BPF_PRELOAD functionionality since they can operate
> without userspace.
>
> Light skeletons were recommended on various mailing list discussions as
> the preffered path to performing signature verification. There are some
> PoCs floating around that used light-skeletons in concert with
> fs-verity/IMA and eBPF LSMs. We took a slightly different approach to
> Hornet, by utilizing the existing PCKS#7 signing scheme that is used for
> kernel modules.
Right, because in the normal skeletons relocation logic remains
unsigned?
I have to admit I don't fully cope how the relocation process translates
into eBPF program but I do get how it is better for signatures if it
does :-)
>
> >> verification. Signature data can be easily generated for the binary
> >
> > s/easily//
> >
> > Useless word having no measure.
> >
>
> Ack, thanks.
>
>
> >> data that is generated via bpftool gen -L. This signature can be
> >
> > I have no idea what that command does.
> >
> > "Signature data can be generated for the binary data as follows:
> >
> > bpftool gen -L
> >
> > <explanation>"
> >
> > Here you'd need to answer to couple of unknowns:
> >
> > 1. What is in exact terms "signature data"?
>
> That is a PKCS#7 signature of a data buffer containing the raw
> instructions of an eBPF program, followed by the initial values of any
> maps used by the program.
Got it, thanks. This motivates to refine my TPM2 asymmetric keys
series so that TPM2 could anchor these :-)
https://lore.kernel.org/linux-integrity/20240528210823.28798-1-jarkko@kernel.org/
>
> > 2. What does "bpftool gen -L" do?
> >
>
> eBPF programs often have 2 parts. An orchestrator/loader program that
> provides load -> attach/run -> i/o -> teardown logic and the in-kernel
> program.
>
> That command is used to generate a skeleton which can be used by the
> orchestrator prgoram. Skeletons get generated as a C header file, that
> contains various autogenerated functions that open and load bpf programs
> as decribed above. That header file ends up being included in a
> userspace orchestrator program or possibly a kernel module.
I did read the man page now too, but thanks for the commentary!
>
> > This feedback maps to other examples too in the cover letter.
> >
> > BR, Jarkko
>
>
> I'll rework this with some definitions of the eBPF subsystem jargon
> along with your suggestions.
Yeah, you should be able to put the gist a factor better to nutshell :-)
>
> -blaise
BR, Jarkko
Powered by blists - more mailing lists