Message-ID: <871puc7wb8.fsf@microsoft.com>
Date: Mon, 31 Mar 2025 13:57:15 -0700
From: Blaise Boscaccy <bboscaccy@...ux.microsoft.com>
To: Jarkko Sakkinen <jarkko@...nel.org>
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

Jarkko Sakkinen <jarkko@...nel.org> writes:

Hi Jarkko,

Thanks for the comments. Paul did a very nice job providing some
background info, allow me to provide some additional data.

> On Fri, Mar 21, 2025 at 09:45:02AM -0700, Blaise Boscaccy wrote:
>> This patch series introduces the Hornet LSM.
>> 
>> Hornet takes a simple approach to light-skeleton-based eBPF signature
>
> Can you define "light-skeleton-based" before using the term.
>
> This is the first time in my life when I hear about it.
>

Sure. Here is the patchset where this stuff got introduced if you are
curious.
https://lore.kernel.org/bpf/20220209054315.73833-1-alexei.starovoitov@gmail.com/

eBPF has similar requirements to that of modules when it comes to
loading: find kallysym addresses, fix up elf relocations, some
struct field offset handing stuff called CO-RE (compile-one
run-anywhere), and some other miscellaneous bookkeeping.  During eBPF
program compilation, pseudo-values get written to the immedate operands
of instructions.  During loading, those pseudo-values get rewritten with
concrete addresses or data applicable to the currently running system,
e.g. a kallsym address or a fd for a map. This needs to happen before
the instructions for a bpf program are loaded into the kernel via the
bpf() syscall.

Unlike modules, an in-kernel loader unfortunately doesn't
exist. Typically, the instruction rewriting is done dynamically in
userspace via libbpf (or the rust/go/python loader). What skeletons do
is generate a script of required instruction-rewriting operations which
then gets played back at load-time against a hard-coded blob of raw
instruction data. This removes the need to distribute source-code or
object files.

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.

>> 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. 

> 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.

> 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.

-blaise

Powered by blists - more mailing lists