On 07/30/2014 10:57 AM, Stephan Wiesand wrote:
> On 2014-07-30, at 17:40, Stephan Wiesand <[log in to unmask]> wrote:
>
>> 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.
> And I have a preliminary 1.6.9 srpm here:
>
> https://claus.ifh.de/owncloud/public.php?service=files&t=d4c59fd89f6ad41418f189c6e9ad4696
>
> It implements most of what was discussed, except for the module signing stuff. I hope to get around to that tomorrow.
>
> The srpm should still work on SL5/6 too and the behaviour unchanged there. On SL7, it should clean up /sbin usage, builds packages with a basename of openafs-1.6-sl (can be overridden at build time, and changing it to openafs16 is a one-liner), and uses systemd unit files.
>
> I have the client running on an SL7 test system, but I'd be surprised if there weren't bugs left all over the place. In particular the systemd stuff may well be less than perfect. Just wanted to give you a chance to look at what I have as early as possible.
>
> Stephan
>

Hey Stephan,

I've been chasing down odds and ends, sorry for the delay.  Connie is 
still our Secure Boot Czar so I've not really chased that down, but for 
the package/systemd side of things stuff looks fairly viable.

I've a few small change requests:

I attached a patch with three fairly minor alterations - two of which 
are in spec file comments

I'm wondering if packages that have %{nsfx} defined should have a 
Provides: on the non nsfx name for ease of yum/kickstart naming.  If I 
don't care between 1.6 or <otherversion> it might be nice if 'yum 
install openafs-client' just worked.  Thoughts?

I'm wondering if the '.generated' suffix can be removed from the 
/etc/sysconfig/ files?

For the systemd --scripts at the end, I noticed you'd coded the 
behaviour.  Any reason against the systemd provided macros: 
http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd

As a general comment on the systemd unit activation, I'd lean towards 
using 'preset' rather than 'enable' and tossing the necessary stanzas to 
enable in %{_prefix}/lib/systemd/system-preset/70-afs-<pkg>.preset  .  I 
think it may make some kinds of administration easier for people down 
the line.

This is probably my ignorance of AFS (which is a lot), but the 
openafs-1.6-sl-krb5 package was not required by openafs-1.6-sl-client. 
That seemed odd to me.  If I'm off base here, don't worry about it; not 
having aklog was 'unexpected' but easily solved.

The packages built up fine and seem to work with FNAL's AFS.

Pat

-- 
Pat Riehecky

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