SCIENTIFIC-LINUX-DEVEL Archives

July 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:
Pat Riehecky <[log in to unmask]>
Reply To:
Pat Riehecky <[log in to unmask]>
Date:
Tue, 29 Jul 2014 10:44:24 -0500
Content-Type:
multipart/mixed
Parts/Attachments:
text/plain (2661 bytes) , template-kmod.spec (2238 bytes)
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'.

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

-- 
Pat Riehecky

Scientific Linux developer
http://www.scientificlinux.org/



ATOM RSS1 RSS2