On 2014-07-29, at 17:44, Pat Riehecky <[log in to unmask]> wrote:

> On 07/29/2014 09:53 AM, Stephan Wiesand wrote:
>> On Jul 25, 2014, at 19:04 , Pat Riehecky wrote:
>> 
>>> For secure boot kmods, it looks like there may be some odd work to be done....
>> Thanks for the hint. I hadn't thought of that yet. Sure, our modules should be signed. I believe this has potential benefits even without UEFI or secure boot.
>> 
>>> I was pointed here for an example:
>>> 
>>> https://messinet.com/rpms/browser/dahdi-linux-kmod/dahdi-linux-kmod.spec
>> 
>> I didn't find that resource particularly helpful. But upstream documentation suggests it's fairly trivial: According to the "signing kernel modules for secure boot" section of the system administrators guide, all it takes is this:
>> 
>> perl /usr/src/kernels/%{kernel}/scripts/sign-file \
>>   sha256 \
>>   SL_signing_key.priv \
>>   SL_signing_key_pub.der \
>>   openafs.ko
>> 
>> The only question is where to find the keys. And, academically, why do they need the public key for creating the signature?
>> 
>> A first proposal: If the build is initiated with "rpmbuild ... --define 'module_key /path/to/SL_key.priv', the spec will attempt to sign the modules with that private key and the corresponding /path/to/SL_key_pub.der as the public key. If module_key is not defined, the modules won't be signed.
>> 
>> Obviously, this proposal could be adapted to whatever scheme you have decided on for naming your key files, or we could have separate %defines for the two files.
>> 
>> - Stephan
>> 
> 
> Our exact secure boot process is still evolving a bit as we wait for our hard token.

Ok.

> The folks over at ELRepo (thanks Phil Perry, Akemi Yagi, and Alan Bartlett) emailed me their kmod template for EL7.  I've attached it here as a useful resource in the whole conversation.
> 
> My main worry is stripping debuginfo breaking the signature. Typically the strip is run after %install which gives us some 'issues'.
> 
> The dahdi spec has one workaround (lines 61-107), but it is huge and somewhat messy looking
> The ELRepo spec is clean and simple yet seems a bit more aggressive (lines 28; 51-52), it leaves us without debuginfo

I'm currently leaning towards borrowing from both dahdi and ELRepo. Much of the dahdi hack is already present in our spec, so I propose we use that and wrap it into the switches and macros as used by ELRepo or at least very similar.

> /usr/lib/rpm/find-debuginfo.sh only strips executable files.

My next preference would indeed be not to strip the kernel modules (I believe this doesn't even waste kernel memory, but I could be wrong) and have no debuginfo package for the kmod.

> As for macros:
> I'd love to keep the macros compatible with pesign's expectations mostly to keep things simple on the build host.

What are pesigns expectations?

> It might be nice if the kmod was signed with a dummy key in the event of 'no key found'.  I believe the kernel does that.  It doesn't really provide any additional assurances, but it may make the spec easier to maintain and test on arbitrary systems.

Creating dummy keys during build may starve due to lack of entropy, but I'll think about it.

> Beyond that, I think I'll have to punt to Connie as she is heading up or Secure Boot stuff.  If I'm off base ignore me.

Sure :-) Seriously though, thanks for pointing out where the devil is.

Stephan

-- 
Stephan Wiesand
DESY - DV -
Platanenallee 6
15738 Zeuthen, Germany