linux-kselftest.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jarkko Sakkinen <jarkko@kernel.org>
To: Blaise Boscaccy <bboscaccy@linux.microsoft.com>
Cc: "Jonathan Corbet" <corbet@lwn.net>,
	"David Howells" <dhowells@redhat.com>,
	"Herbert Xu" <herbert@gondor.apana.org.au>,
	"David S. Miller" <davem@davemloft.net>,
	"Paul Moore" <paul@paul-moore.com>,
	"James Morris" <jmorris@namei.org>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	"Masahiro Yamada" <masahiroy@kernel.org>,
	"Nathan Chancellor" <nathan@kernel.org>,
	"Nicolas Schier" <nicolas@fjasle.eu>,
	"Shuah Khan" <shuah@kernel.org>,
	"Mickaël Salaün" <mic@digikod.net>,
	"Günther Noack" <gnoack@google.com>,
	"Nick Desaulniers" <nick.desaulniers+lkml@gmail.com>,
	"Bill Wendling" <morbo@google.com>,
	"Justin Stitt" <justinstitt@google.com>,
	"Jan Stancek" <jstancek@redhat.com>,
	"Neal Gompa" <neal@gompa.dev>,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	keyrings@vger.kernel.org, linux-crypto@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	linux-kbuild@vger.kernel.org, linux-kselftest@vger.kernel.org,
	bpf@vger.kernel.org, llvm@lists.linux.dev, nkapron@google.com,
	teknoraver@meta.com, roberto.sassu@huawei.com,
	xiyou.wangcong@gmail.com
Subject: Re: [RFC PATCH security-next 0/4] Introducing Hornet LSM
Date: Tue, 1 Apr 2025 18:50:02 +0300	[thread overview]
Message-ID: <Z-wLKhlfJ5EQqvJC@kernel.org> (raw)
In-Reply-To: <871puc7wb8.fsf@microsoft.com>

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

  reply	other threads:[~2025-04-01 15:50 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-21 16:45 [RFC PATCH security-next 0/4] Introducing Hornet LSM Blaise Boscaccy
2025-03-21 16:45 ` [RFC PATCH security-next 1/4] security: " Blaise Boscaccy
2025-03-21 17:32   ` Jonathan Corbet
2025-03-31 20:09     ` Blaise Boscaccy
2025-03-21 22:29   ` sergeh
2025-03-31 20:08     ` Blaise Boscaccy
2025-04-03 15:40   ` Paul Moore
2025-03-21 16:45 ` [RFC PATCH security-next 2/4] hornet: Introduce sign-ebpf Blaise Boscaccy
2025-03-22 17:27   ` Jarkko Sakkinen
2025-03-31 20:00     ` Blaise Boscaccy
2025-03-21 16:45 ` [RFC PATCH security-next 3/4] hornet: Add an example lskel data extactor script Blaise Boscaccy
2025-03-22 17:25   ` Jarkko Sakkinen
2025-03-31 20:04     ` Blaise Boscaccy
2025-03-21 16:45 ` [RFC PATCH security-next 4/4] selftests/hornet: Add a selftest for the hornet LSM Blaise Boscaccy
2025-03-21 21:43 ` [RFC PATCH security-next 0/4] Introducing Hornet LSM Paul Moore
2025-03-22 17:22 ` Jarkko Sakkinen
2025-03-22 20:44   ` Paul Moore
2025-03-22 20:48     ` Paul Moore
2025-03-22 21:43       ` Jarkko Sakkinen
2025-03-22 21:42     ` Jarkko Sakkinen
2025-03-31 20:57   ` Blaise Boscaccy
2025-04-01 15:50     ` Jarkko Sakkinen [this message]
2025-04-01 18:56       ` Blaise Boscaccy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z-wLKhlfJ5EQqvJC@kernel.org \
    --to=jarkko@kernel.org \
    --cc=bboscaccy@linux.microsoft.com \
    --cc=bpf@vger.kernel.org \
    --cc=corbet@lwn.net \
    --cc=davem@davemloft.net \
    --cc=dhowells@redhat.com \
    --cc=gnoack@google.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=jmorris@namei.org \
    --cc=jstancek@redhat.com \
    --cc=justinstitt@google.com \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=llvm@lists.linux.dev \
    --cc=masahiroy@kernel.org \
    --cc=mic@digikod.net \
    --cc=morbo@google.com \
    --cc=nathan@kernel.org \
    --cc=neal@gompa.dev \
    --cc=nick.desaulniers+lkml@gmail.com \
    --cc=nicolas@fjasle.eu \
    --cc=nkapron@google.com \
    --cc=paul@paul-moore.com \
    --cc=roberto.sassu@huawei.com \
    --cc=serge@hallyn.com \
    --cc=shuah@kernel.org \
    --cc=teknoraver@meta.com \
    --cc=xiyou.wangcong@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).