See http://www.infradead.org/rpr.html

Luis R. Rodriguez [off-list ref] wrote:

quoted

"PKCS#7: Add an optional authenticated attribute to hold firmware name"
https://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/commit/?h=fwsign-pkcs7&id=1448377a369993f864915743cfb34772e730213good

        1.3.6.1.4.1.2312.16     Linux kernel
        1.3.6.1.4.1.2312.16.2   - PKCS#7/CMS SignerInfo attribute types
        1.3.6.1.4.1.2312.16.2.1   - firmwareName

I take it you are referring to this?

Yes.

quoted

If we follow this model we'd then need something like:

        1.3.6.1.4.1.2312.16.2.2   - seLinuxPolicyName

That should mean each OID that has different file names would need to be
explicit about and have a similar entry on the registry. I find that
pretty
redundant and would like to avoid that if possible.

firmwareName is easy for people to understand - it's the name the kernel
asks
for and the filename of the blob.  seLinuxPolicyName is, I think, a lot
more
tricky since a lot of people don't use SELinux, and most that do don't
understand it (most people that use it aren't even really aware of it).

If you can use the firmwareName as the SELinux/LSM key, I would suggest
doing
so - even if you dress it up as a path (/lib/firmware/<firmwareName>).

David

In conversation with Mimi last week she was very keen on the model where
we load modules & firmware in such a fashion that the kernel has access to
the original inode -- by passing in a f2f, or in the firmware case by
doing the rd lookup directly. So surely you have all the SELinux labelling
you need?

-- 
dwmw2