Message-ID: <beaa81748cf1325df67930bf74ea87e6cdcb3e46.camel@HansenPartnership.com>
Date: Wed, 14 May 2025 11:39:16 -0400
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: KP Singh <kpsingh@...nel.org>, Paul Moore <paul@...l-moore.com>
Cc: bboscaccy@...ux.microsoft.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,  kysrinivasan@...il.com
Subject: Re: [PATCH v3 0/4] Introducing Hornet LSM

On Sun, 2025-05-11 at 04:01 +0200, KP Singh wrote:
[...]
> > 
> For this specific BPF case, we will directly sign a composite of the
> first message and the hash of the second. Let H_meta = H(M_metadata).
> The block to be signed is effectively:
> 
>     B_signed = I_loader || H_meta
> 
> The signature generated is Sig(B_signed).
> 
> The process then follows a similar pattern to the Alice and Bob
> model,
> where the kernel (Bob) verifies I_loader and H_meta using the
> signature. Then, the trusted I_loader is responsible for verifying
> M_metadata against the trusted H_meta.
> 
> From an implementation standpoint:
> 
> # Build
> 
> bpftool (or some other tool in the user's build environment) knows
> about the metadata (M_metadata) and the loader program (I_loader). It
> first calculates H_meta = H(M_metadata). Then it constructs the
> object
> to be signed and computes the signature:
> 
>     Sig(I_loader || H_meta)
> 
> # Loader
> 
> bpftool generates the loader program. The initial instructions of
> this loader program are designed to verify the SHA256 hash of the
> metadata (M_metadata) that will be passed in a map. These
> instructions effectively embed the precomputed H_meta as immediate
> values.
> 
>     ld_imm64 r1, const_ptr_to_map // insn[0].src_reg ==
> BPF_PSEUDO_MAP_IDX
>     r2 = *(u64 *)(r1 + 0);
>     ld_imm64 r3, sha256_of_map_part1 // constant precomputed by
> bpftool (part of H_meta)
>     if r2 != r3 goto out;
> 
>     r2 = *(u64 *)(r1 + 8);
>     ld_imm64 r3, sha256_of_map_part2 // (part of H_meta)
>     if r2 != r3 goto out;
> 
>     r2 = *(u64 *)(r1 + 16);
>     ld_imm64 r3, sha256_of_map_part3 // (part of H_meta)
>     if r2 != r3 goto out;
> 
>     r2 = *(u64 *)(r1 + 24);
>     ld_imm64 r3, sha256_of_map_part4 // (part of H_meta)
>     if r2 != r3 goto out;
>     ...
> 
> This implicitly makes the payload equivalent to the signed block
> (B_signed)
> 
>     I_loader || H_meta
> 
> bpftool then generates the signature of this I_loader payload (which
> now contains the expected H_meta) using a key (system or user) with
> new flags that work in combination with bpftool -L

Could I just push back a bit on this.  The theory of hash chains (which
I've cut to shorten) is about pure data structures.  The reason for
that is that the entire hash chain is supposed to be easily
independently verifiable in any environment because anything can
compute the hashes of the blocks and links.  This independent
verification of the chain is key to formally proving hash chains to be
correct.  In your proposal we lose the easy verifiability because the
link hash is embedded in the ebpf loader program which has to be
disassembled to do the extraction of the hash and verify the loader is
actually checking it.

I was looking at ways we could use a pure hash chain (i.e. signature
over loader and real map hash) and it does strike me that the above
ebpf hash verification code is pretty invariant and easy to construct,
so it could run as a separate BPF fragment that then jumps to the real
loader.  In that case, it could be constructed on the fly in a trusted
environment, like the kernel, from the link hash in the signature and
the signature could just be Sig(loader || map hash) which can then be
easily verified without having to disassemble ebpf code.  So we get the
formal provability benefits of using a real hash chain while still
keeping your verification in BPF. 

Regards,

James

Powered by blists - more mailing lists