Re: Linux Firmware Signing

From: Kees Cook
Date: Tue Sep 01 2015 - 23:08:45 EST

On Tue, Sep 1, 2015 at 4:43 PM, Luis R. Rodriguez <mcgrof@xxxxxxxx> wrote:
> On Mon, Aug 31, 2015 at 10:18:55AM -0400, Mimi Zohar wrote:
>> > > eBPF/seccomp
> OK I knew nothing about this but I just looked into it, here are my notes:
> * old BPF - how far do we want to go? This goes so far as to parsing
> user passed void __user *arg data through ioctls which typically
> gets copy_from_user()'d and eventually gets BPF_PROG_RUN().
> * eBPF:
> seccomp() & prctl_set_seccomp()
> |
> V
> do_seccomp()
> |
> V
> seccomp_set_mode_filter()
> |
> V
> seccomp_prepare_user_filter()
> |
> V
> bpf_prog_create_from_user() (seccomp) \
> bpf_prog_create() > bpf_prepare_filter()
> sk_attach_filter() /
> All approaches come from user passed data, nothing fd based.
> For both old BPF and eBPF then:
> If we wanted to be paranoid I suppose the Machine Owner Key (MOK)
> Paul had mentioned up could be used to vet for passed filters, or
> a new interface to enable fd based filters. This really would limit
> the dynamic nature of these features though.
> eBPF / secccomp would not be the only place in the kernel that would have
> issues with user passed data, we have tons of places the same applies so
> implicating the old BPF / eBPF / seccomp approaches can easily implicate
> many other areas of the kernel, that's pretty huge but from the looks of
> it below you seem to enable that to be a possibility for us to consider.

At the time (LSS 2014?) I argued that seccomp policies come from
binaries, which are already being measured. And that policies only
further restrict a process, so there seems to be to be little risk in
continuing to leave them unmeasured.


Kees Cook
Chrome OS Security
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at