SCIENTIFIC-LINUX-DEVEL Archives

August 2014

SCIENTIFIC-LINUX-DEVEL@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Connie Sieh <[log in to unmask]>
Reply To:
Connie Sieh <[log in to unmask]>
Date:
Wed, 13 Aug 2014 16:40:22 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (81 lines)
On Tue, 29 Jul 2014, Pat Riehecky 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.
>
> 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'.

Yes the signing has to be done after "strips" have been done other wise 
strip will strip the signatures.

>
> 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
>
> /usr/lib/rpm/find-debuginfo.sh only strips executable files.
>
> As for macros:
> I'd love to keep the macros compatible with pesign's expectations mostly to 
> keep things simple on the build host.
> 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.
>
> 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.
>
> Pat
>
>


-connie

ATOM RSS1 RSS2