linux-kernel - Re: [RFC PATCH security-next 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: <87friru2vr.fsf@microsoft.com>
Date: Tue, 01 Apr 2025 11:56:40 -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:

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

Yup, Exactly. 

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

Oooh. That would be very nice :) 

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