Lukas Wunner <lukas@xxxxxxxxx> writes:
> On Wed, May 28, 2025 at 02:49:03PM -0700, Blaise Boscaccy wrote:
>> + if (!attr->signature_maps_size) {
>> + sha256((u8 *)prog->insnsi, prog->len * sizeof(struct bpf_insn), (u8 *)&hash);
>> + err = verify_pkcs7_signature(hash, sizeof(hash), signature, attr->signature_size,
>> + VERIFY_USE_SECONDARY_KEYRING,
>> + VERIFYING_EBPF_SIGNATURE,
>> + NULL, NULL);
>
> Has this ever been tested?
>
> It looks like it will always return -EINVAL because:
>
> verify_pkcs7_signature()
> verify_pkcs7_message_sig()
> pkcs7_verify()
>
> ... pkcs7_verify() contains a switch statement which you're not
> amending with a "case VERIFYING_EBPF_SIGNATURE" but which returns
> -EINVAL in the "default" case.
>
Looks like I missed a commit when sending this patchset. Thanks for
finding that.
> Aside from that, you may want to consider introducing a new ".ebpf"
> keyring to allow adding trusted keys specifically for eBPF verification
> without having to rely on the system keyring.
>
> Constraining oneself to sha256 doesn't seem future-proof.
>
Definitely not a bad idea, curious, how would you envision that looking
from an UAPI perspective?
> Some minor style issues in the commit message caught my eye:
>
>> This introduces signature verification for eBPF programs inside of the
>> bpf subsystem. Two signature validation schemes are included, one that
>
> Use imperative mood, avoid repetitive "This ...", e.g.
> "Introduce signature verification of eBPF programs..."
>
>> The signature check is performed before the call to
>> security_bpf_prog_load. This allows the LSM subsystem to be clued into
>> the result of the signature check, whilst granting knowledge of the
>> method and apparatus which was employed.
>
> "Perform the signature check before calling security_bpf_prog_load()
> to allow..."
>
> Thanks,
>
> Lukas
