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:
Stephan Wiesand <[log in to unmask]>
Reply To:
Stephan Wiesand <[log in to unmask]>
Date:
Tue, 29 Jul 2014 16:53:53 +0200
Content-Type:
text/plain
Parts/Attachments:
text/plain (33 lines)
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

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

ATOM RSS1 RSS2