This was based on the complaint from Davem that the "make
allmodconfig" build got way slower because module signing takes a
while.
And quite frankly, the whole "extra strip and sign" thing at modpost
time was just nasty ugly code.
Why don't we do something *much* simpler? We already have a
conditional stripping of modules (that whole INSTALL_MOD_STRIP) logic,
and it really simplifies everything if we just do something very
similar for the signing of modules. At "make modules_install" time,
exactly like the stripping is done.
Sure, it means that if you want to load modules directly from your
kernel build tree (without installing them), you'd better be running a
kernel that doesn't need the signing (or you need to sign things
explicitly). But seriously, nobody cares. If you are building a module
after booting the kernel with the intention of loading that modified
module, you aren't going to be doing that whole module signing thing
*anyway*. Signed modules make sense when building the kernel and
module together, so signing them as we install the kernel and module
is just sensible.
And it really is much simpler as shown by the diffstat: 13
insertions(+), 78 deletions(-).
It seems to work for me from my (very very limited) testing. Comments?
Linus
Linus Torvalds <[email protected]> wrote:
> This was based on the complaint from Davem that the "make
> allmodconfig" build got way slower because module signing takes a
> while.
>
> And quite frankly, the whole "extra strip and sign" thing at modpost
> time was just nasty ugly code.
>
> Why don't we do something *much* simpler? We already have a
> conditional stripping of modules (that whole INSTALL_MOD_STRIP) logic,
> and it really simplifies everything if we just do something very
> similar for the signing of modules. At "make modules_install" time,
> exactly like the stripping is done.
>From the point of view of generating Fedora/RHEL kernel RPMs, we probably
don't want to sign even at that point. We want to do make modules_install,
run the debuginfo generator, then strip thoroughly and *then* sign.
As I understand it, Josh Boyer has a patch based on older code that adds a
modules_sign target or something like that signs the modules in their place of
installation as a separate step. Even that much isn't really necessary:
there's a script provided to sign a module - it isn't necessary for the kernel
build to actually do it. You can do it manually with:
find $install_path -name "*.ko" | while read x
do
strip-as-appropriate $x
./scripts/sign-file $key $x509 $x $x
done
This is covered in the last part of Josh's blog entry on the subject:
http://jwboyer.livejournal.com/44787.html
> Sure, it means that if you want to load modules directly from your
> kernel build tree (without installing them),
Which I do, especially for maintaining this. It's much easier and quicker to
boot my test machine directly out of the build tree than have to build a fresh
kernel package and, especially, install it on the test machine each time I
make a change:-).
> you'd better be running a kernel that doesn't need the signing (or you need
> to sign things explicitly). But seriously, nobody cares.
True. The only ones who really matter are the distribution kernels (including
things like Android in that). They represent the vast majority of users of
kernels. Everyone else is just in the noise - myself included, I guess.
> If you are building a module after booting the kernel with the intention of
> loading that modified module, you aren't going to be doing that whole module
> signing thing *anyway*.
You are mistaken in that. We *do* want to be able to do this. That's why
there's an extra_certificates file.
> Signed modules make sense when building the kernel and module together, so
> signing them as we install the kernel and module is just sensible.
>
> And it really is much simpler as shown by the diffstat: 13
> insertions(+), 78 deletions(-).
>
> It seems to work for me from my (very very limited) testing. Comments?
It's probably even better to just get rid of all the automatic module signing
stuff completely and leave the sign-file script for the builder to use
manually. The module verification code will still be present.
It would also be nice to get rid of the key autogeneration stuff. I'm not
keen on the idea of unparameterised key autogeneration - anyone signing their
modules should really supply the appropriate address elements. If we aren't
signing modules automatically, we can just insert an empty certificate if one
is not supplied to make allyes/modconfig work.
Distribution kernel packaging scripts (RPM spec files for example) can do the
key generation and the module signing from within the packaging fluff by
calling the script(s) the kernel provides.
We could then, perhaps, get rid of the extra_certificates file and just have
one certificates file that is the list of certs that get compiled into the
kernel, which can be filled in by the builder - though we still need access to
the specific X.509 certificate when signing so that we can put an ID into the
signature attached to the module.
David
On Wed, Oct 17, 2012 at 4:36 PM, Linus Torvalds
<[email protected]> wrote:
> This was based on the complaint from Davem that the "make
> allmodconfig" build got way slower because module signing takes a
> while.
>
> And quite frankly, the whole "extra strip and sign" thing at modpost
> time was just nasty ugly code.
>
> Why don't we do something *much* simpler? We already have a
> conditional stripping of modules (that whole INSTALL_MOD_STRIP) logic,
> and it really simplifies everything if we just do something very
> similar for the signing of modules. At "make modules_install" time,
> exactly like the stripping is done.
That is indeed simpler for the "build your own kernel" set of people.
There's really nothing wrong with doing it from that perspective. It's
a bit less safe than what David has now, but it achieves the goal of
making kernel _builds_ faster.
> Sure, it means that if you want to load modules directly from your
> kernel build tree (without installing them), you'd better be running a
> kernel that doesn't need the signing (or you need to sign things
> explicitly). But seriously, nobody cares. If you are building a module
> after booting the kernel with the intention of loading that modified
> module, you aren't going to be doing that whole module signing thing
> *anyway*. Signed modules make sense when building the kernel and
> module together, so signing them as we install the kernel and module
> is just sensible.
Right, if you're building your own.
> It seems to work for me from my (very very limited) testing. Comments?
The downside is that it won't work for distros. Or at least the distros
using RPM's debuginfo subpackage mechanism. There's a blog post here:
http://jwboyer.livejournal.com/44787.html
that covers why in greater detail, but the short if it is that the
kernel is built by RPM, installed into the RPM_BUILD_ROOT, and _then_
the debuginfo generation is done. So that strips the signature off of
the module at that point and the final kernel RPM winds up with no
signed modules.
I'll cleanup the patch we're currently carrying in Fedora and send it
to the list tomorrow. My apologies for not getting it done today, but
I'm a bit jet lagged and trying to catch up on other things after being
gone for a few days.
josh
On Wed, Oct 17, 2012 at 3:19 PM, David Howells <[email protected]> wrote:
>
> It's probably even better to just get rid of all the automatic module signing
> stuff completely and leave the sign-file script for the builder to use
> manually. The module verification code will still be present.
That's just disgusting crazy talk.
Christ, David, get a grip on yourself. You seem to dismiss the "people
want to build their own kernel" people entirely.
One of the main sane use-cases for module signing is:
- CONFIG_CHECK_SIGNATURE=y
- randomly generated one-time key
- "make modules_install; make install"
- "make clean" to get rid of the keys.
- reboot.
and now you have a custom kernel that has the convenience of modules,
yet is basically as safe as a non-modular build. The above makes it
much harder for any kind of root-kit module to be loaded, and
basically entirely avoids one fundamental security scare of modules.
Everything else is garbage and should largely be ignored. Distro
people who want to use magic distro keys can do whatever the hell they
want with their modules, they'll have a separate packaging phase
anyway for their secret keys - and they'll have to do it separately
anyway just to keep their private key safe.
And the UEFI "we only boot kernels signed by microsoft keys" case is
just BS, and while it might be useful for some people, it's more
likely to be a pain.
In contrast, the case I outlined above is about true *security*, not
some "vendor control" bullshit. And THAT is the case that kernel
developers should encourage: using cryptography to secure individual
users, instead of controlling things for others.
Quite frankly, your "get rid of all the automatic module signing stuff
completely" answer makes me think that your agenda is fundamentally
flawed. Module signing is *not* about some magic redhat or microsoft
key, and anybody who thinks it *should* be about that should seriously
rethink their position.
In fact, if I believed this was about redhat or microsoft keys, I
would never have merged the code at all.
Linus
On Wed, Oct 17, 2012 at 3:26 PM, Josh Boyer <[email protected]> wrote:
>
> The downside is that it won't work for distros. Or at least the distros
> using RPM's debuginfo subpackage mechanism.
Hmm. It *should* work for them too, because the debuginfo modules stay
around in the object tree, and never get stripped there. None of this
is different from what we used to do before: we stripped the modules
as we copied them to /lib/modules (where the RPM build obviously would
have that $RPM_BUILD_ROOT prefix on the module install path).
Anyway, I seriously think that the kernel build should worry about
*users*, not about the distro building their binaries. And I do think
the current mess is unacceptable (following the insane
"stripped->extra stripping->signed->potentially stripped *again* at
install time" code was just insane). I may not have reacted as much as
David to the actual build having slowed down, but having looked at the
makefiles, there really is no excuse for that mess.
Linus
On Wed, Oct 17, 2012 at 7:07 PM, Linus Torvalds
<[email protected]> wrote:
> On Wed, Oct 17, 2012 at 3:26 PM, Josh Boyer <[email protected]> wrote:
>>
>> The downside is that it won't work for distros. Or at least the distros
>> using RPM's debuginfo subpackage mechanism.
>
> Hmm. It *should* work for them too, because the debuginfo modules stay
> around in the object tree, and never get stripped there. None of this
Debuginfo is run on the installed tree ($RPM_BUILD_ROOT), not the
object tree. It's how RPM works. It kind of has to because it should
only create debuginfo files for files that are actually installed by
the RPM.
I know it's no different from how it _used_ to work with stripped
modules, but that's a problem that was solved a while ago. The existing
build system works for both users and distros in that regard, and that
is my goal for modsigning too.
> Anyway, I seriously think that the kernel build should worry about
> *users*, not about the distro building their binaries. And I do think
> the current mess is unacceptable (following the insane
> "stripped->extra stripping->signed->potentially stripped *again* at
> install time" code was just insane). I may not have reacted as much as
> David to the actual build having slowed down, but having looked at the
> makefiles, there really is no excuse for that mess.
I'm not saying your patch is wrong. I'm not even saying it isn't
better. I'm simply saying it doesn't work as-is for distros.
What I'd like to do is come up with a solution that works for both
cases. E.g. if we take your patch and apply it, but also create a
config option and a 'make modules_sign' target to sign them in the
installed tree and not at 'modules_install' time. Or something along
those lines.
Distros want to do this too, and have been doing this for a while. It
might be required for Secure Boot in some distro's eyes, but that is
really a side effect. Distros _are_ users. Or if you're not as starry
eyed as I am, they're at least a gateway for a large number of users.
I want those people to get the benefits of signed modules and I'd really
like to do it without the distros having to carry patches or do further
monkeying around after the buildsystem is done. That's all.
josh
On Wed, Oct 17, 2012 at 4:07 PM, Linus Torvalds
<[email protected]> wrote:
>
> Hmm. It *should* work for them too, because the debuginfo modules stay
> around in the object tree, and never get stripped there. None of this
> is different from what we used to do before: we stripped the modules
> as we copied them to /lib/modules (where the RPM build obviously would
> have that $RPM_BUILD_ROOT prefix on the module install path).
Ok, I read your description of the odd way fedora builds debuginfo kernels.
I actually think that works fine too. I do agree with adding a "make
sign_modules" target, but it would *re-sign* them after "make
modules_install" has already signed them once.
Why?
What you'd do for your debuginfo requirements is:
- do the normal kernel build, and install modules (with *my* patch,
which does signing at install time)
This does the normal (conditionally stripped - you just wouldn't
strip them, but you cannot have done that before either) modules,
installs them, and signs then.
Ta-daa, you have your debuginfo modules installed, and they are
signed. Create the debuginfo rpm.
- now, strip the modules. This obviously destroys the signatures
- do the extra "make sign_modules" that you added, that re-signs the
already installed modules, and now you can create the non-debuginfo
rpm.
Voila. "make modules_install" does the right thing for everybody -
including normal users. And it does so without the incredible baroque
code. And no normal user is expected to ever use the new "make
sign_modules", but it allows for the Fedora "we'll want to sign them
again".
That said, you could even just do "make sign-modules" on your own
without any makefile targets. After all, it would just be something
like
find $MODULEDIR --name '*.ko | while read i; do script/sign-file
keyfile x509file $i; done
so it could even be done in that rpm script directly.
Linus
On Wed, Oct 17, 2012 at 4:20 PM, Josh Boyer <[email protected]> wrote:
>
> Debuginfo is run on the installed tree ($RPM_BUILD_ROOT), not the
> object tree. It's how RPM works. It kind of has to because it should
> only create debuginfo files for files that are actually installed by
> the RPM.
Yeah, I just read your blog post, and sent a suggested "here's how it works".
It really should work fine with the much simplified module-signing
rules too. Yes, you may want to add a "make module-sign" target to
*re*-sign modules after you've mucked with them, but you don't really
even need that. You could just as easily just do the re-signing
directly.
The point being that I'm pretty sure you really don't need that odd
dance at modpost time. And having "make modules_install" sign the
modules it installs (unstripped, for your use case) actually works for
the rpm package too.
Linus
On Wed, Oct 17, 2012 at 4:25 PM, Linus Torvalds
<[email protected]> wrote:
>
> It really should work fine with the much simplified module-signing
> rules too.
Actually, my "much simplified modules-install" is a bit broken.
It worked for me last time (I'm running that kernel and modules now),
but I just triggered a
INSTALL Documentation/connector/cn_test.ko
Can't read Signer name
error.
My patch is broken, and I simplified a bit *too* much. In particular
the .signer and .keyid logic got thrown out with the bathwater.
I just hadn't noticed until I did a "git clean", because the old
signer/keyid files had stayed around, hiding the breakage.
I'll send out a fixed patch asap,
Linus
On Wed, Oct 17, 2012 at 4:44 PM, Linus Torvalds
<[email protected]> wrote:
>
> I'll send out a fixed patch asap,
Ok, this is not pretty, and I think it generates the .signer and
.keyid files at the wrong time.
I do the kernel build as a regular user, and just "make install" as
root, and now it generates those turds as root-owned files. Ugly.
But I took the code from the parts I had deleted in my over-eager
"delete as much as possible of the strip-and-sign code", and moved it
to the install phase. So this is the obvious quick fix, but I'm sure
there are better solutions.
Linus
On Wed, Oct 17, 2012 at 7:21 PM, Linus Torvalds
<[email protected]> wrote:
> On Wed, Oct 17, 2012 at 4:07 PM, Linus Torvalds
> <[email protected]> wrote:
>>
>> Hmm. It *should* work for them too, because the debuginfo modules stay
>> around in the object tree, and never get stripped there. None of this
>> is different from what we used to do before: we stripped the modules
>> as we copied them to /lib/modules (where the RPM build obviously would
>> have that $RPM_BUILD_ROOT prefix on the module install path).
>
> Ok, I read your description of the odd way fedora builds debuginfo kernels.
>
> I actually think that works fine too. I do agree with adding a "make
> sign_modules" target, but it would *re-sign* them after "make
> modules_install" has already signed them once.
>
> Why?
>
> What you'd do for your debuginfo requirements is:
>
> - do the normal kernel build, and install modules (with *my* patch,
> which does signing at install time)
>
> This does the normal (conditionally stripped - you just wouldn't
> strip them, but you cannot have done that before either) modules,
> installs them, and signs then.
>
> Ta-daa, you have your debuginfo modules installed, and they are
> signed. Create the debuginfo rpm.
>
> - now, strip the modules. This obviously destroys the signatures
find-debuginfo.sh is what creates the debuginfo RPM. It strips the
module debug symbols (and the signature), so there's no need to further
strip things at this point.
> - do the extra "make sign_modules" that you added, that re-signs the
> already installed modules, and now you can create the non-debuginfo
> rpm.
OK, sounds sane at first glance.
> Voila. "make modules_install" does the right thing for everybody -
> including normal users. And it does so without the incredible baroque
> code. And no normal user is expected to ever use the new "make
> sign_modules", but it allows for the Fedora "we'll want to sign them
> again".
>
> That said, you could even just do "make sign-modules" on your own
> without any makefile targets. After all, it would just be something
> like
>
> find $MODULEDIR --name '*.ko | while read i; do script/sign-file
> keyfile x509file $i; done
>
> so it could even be done in that rpm script directly.
Sure, as long as the script is in the kernel tree (or at least I would
like it to be). When I wrote the patch, _none_ of the modsign stuff was
in-tree at the time so I had to carry and adapt things as the code
changed along the way. In my defense, I did say I have to clean it up
still. :)
josh
On Wed, Oct 17, 2012 at 03:44:28PM -0700, Linus Torvalds wrote:
> On Wed, Oct 17, 2012 at 3:19 PM, David Howells <[email protected]> wrote:
> >
> > It's probably even better to just get rid of all the automatic module signing
> > stuff completely and leave the sign-file script for the builder to use
> > manually. The module verification code will still be present.
>
> That's just disgusting crazy talk.
>
> Christ, David, get a grip on yourself. You seem to dismiss the "people
> want to build their own kernel" people entirely.
>
> One of the main sane use-cases for module signing is:
>
> - CONFIG_CHECK_SIGNATURE=y
> - randomly generated one-time key
> - "make modules_install; make install"
> - "make clean" to get rid of the keys.
> - reboot.
I want that too, but right now 'make clean' leaves the keys around,
which seems a bit dangerous to me.
David, why aren't the keys cleaned up as well? Was that on purpose or
just an oversight?
thanks,
greg k-h
On Wed, Oct 17, 2012 at 5:54 PM, Greg KH <[email protected]> wrote:
>>
>> One of the main sane use-cases for module signing is:
>>
>> - CONFIG_CHECK_SIGNATURE=y
>> - randomly generated one-time key
>> - "make modules_install; make install"
>> - "make clean" to get rid of the keys.
>> - reboot.
>
> I want that too, but right now 'make clean' leaves the keys around,
> which seems a bit dangerous to me.
Oh, yes, we should make sure the key file gets cleaned up at "make clean".
I have to admit that I never do the whole "make clean/distclean" any
more, I have gotten so used to just going
git clean -dqfx
to get rid of all generated files in a git directory that I no longer
depend on the makefile getting it right for me.
Linus
Linus Torvalds <[email protected]> writes:
> This was based on the complaint from Davem that the "make
> allmodconfig" build got way slower because module signing takes a
> while.
>
> And quite frankly, the whole "extra strip and sign" thing at modpost
> time was just nasty ugly code.
>
> Why don't we do something *much* simpler? We already have a
> conditional stripping of modules (that whole INSTALL_MOD_STRIP) logic,
> and it really simplifies everything if we just do something very
> similar for the signing of modules. At "make modules_install" time,
> exactly like the stripping is done.
I generally hate "make install" targets which build stuff, but at it's
hard to argue with the diffstat.
You cut too much: you need genkeyid. We don't want to do this at 'make
modules_install' time, so I made it depend on kernel/modsign_pubkey.o
which means it's easiest to move the script. Though since signing is so
slow, I wonder if sign-file should just include the code to extract the
keyid and signer every time.
And in a moment of optimism I tried 'make modules_install MODLIB=.' to
sign modules in-place. It deleted my kernel/ dir. Don't recommend.
Cheers,
Rusty.
Makefile | 11 +++++
kernel/Makefile | 9 +++-
scripts/x509keyid => kernel/x509keyid.pl | 0
scripts/Makefile.modinst | 9 +++-
scripts/Makefile.modpost | 77 +-----------------------------
scripts/sign-file | 2 +-
6 files changed, 29 insertions(+), 79 deletions(-)
diff --git a/Makefile b/Makefile
index 5be2ee8..7b68a5a 100644
--- a/Makefile
+++ b/Makefile
@@ -717,6 +717,17 @@ endif # INSTALL_MOD_STRIP
export mod_strip_cmd
+ifeq ($(CONFIG_MODULE_SIG),y)
+MODSECKEY = ./signing_key.priv
+MODPUBKEY = ./signing_key.x509
+export MODPUBKEY
+mod_sign_cmd = sh $(srctree)/scripts/sign-file $(MODSECKEY) $(MODPUBKEY)
+else
+mod_sign_cmd = true
+endif
+export mod_sign_cmd
+
+
ifeq ($(KBUILD_EXTMOD),)
core-y += kernel/ mm/ fs/ ipc/ security/ crypto/ block/
diff --git a/kernel/Makefile b/kernel/Makefile
index 0dfeca4..f7abe6c 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -139,7 +139,14 @@ ifeq ($(CONFIG_MODULE_SIG),y)
extra_certificates:
touch $@
-kernel/modsign_pubkey.o: signing_key.x509 extra_certificates
+quiet_cmd_genkeyid = GENKEYID $@
+ cmd_genkeyid = $(PERL) $(src)/x509keyid.pl $< $<.signer $<.keyid
+
+%.signer %.keyid: %
+ $(call if_changed,genkeyid)
+
+kernel/modsign_pubkey.o: signing_key.x509 extra_certificates $(MODPUBKEY).signer $(MODPUBKEY).keyid
+
###############################################################################
#
diff --git a/scripts/x509keyid b/kernel/x509keyid.pl
similarity index 100%
rename from scripts/x509keyid
rename to kernel/x509keyid.pl
diff --git a/scripts/Makefile.modinst b/scripts/Makefile.modinst
index 3d13d3a..5c564fc 100644
--- a/scripts/Makefile.modinst
+++ b/scripts/Makefile.modinst
@@ -17,7 +17,7 @@ __modinst: $(modules)
@:
quiet_cmd_modules_install = INSTALL $@
- cmd_modules_install = mkdir -p $(2); cp $@ $(2) ; $(mod_strip_cmd) $(2)/$(notdir $@)
+ cmd_modules_install = mkdir -p $(2); cp $@ $(2) ; $(mod_strip_cmd) $(2)/$(notdir $@) ; $(mod_sign_cmd) $(2)/$(notdir $@)
# Modules built outside the kernel source tree go into extra by default
INSTALL_MOD_DIR ?= extra
@@ -28,6 +28,13 @@ modinst_dir = $(if $(KBUILD_EXTMOD),$(ext-mod-dir),kernel/$(@D))
$(modules):
$(call cmd,modules_install,$(MODLIB)/$(modinst_dir))
+quiet_cmd_genkeyid = GENKEYID $@
+ cmd_genkeyid = \
+ perl $(SCRIPTS_DIR)/x509keyid $< $<.signer $<.keyid
+
+%.signer %.keyid: %
+ $(call if_changed,genkeyid)
+
# Declare the contents of the .PHONY variable as phony. We keep that
# information in a variable se we can use it in if_changed and friends.
diff --git a/scripts/Makefile.modpost b/scripts/Makefile.modpost
index 0020891..a1cb022 100644
--- a/scripts/Makefile.modpost
+++ b/scripts/Makefile.modpost
@@ -14,8 +14,7 @@
# 3) create one <module>.mod.c file pr. module
# 4) create one Module.symvers file with CRC for all exported symbols
# 5) compile all <module>.mod.c files
-# 6) final link of the module to a <module.ko> (or <module.unsigned>) file
-# 7) signs the modules to a <module.ko> file
+# 6) final link of the module to a <module.ko> file
# Step 3 is used to place certain information in the module's ELF
# section, including information such as:
@@ -33,8 +32,6 @@
# Step 4 is solely used to allow module versioning in external modules,
# where the CRC of each module is retrieved from the Module.symvers file.
-# Step 7 is dependent on CONFIG_MODULE_SIG being enabled.
-
# KBUILD_MODPOST_WARN can be set to avoid error out in case of undefined
# symbols in the final module linking stage
# KBUILD_MODPOST_NOFINAL can be set to skip the final link of modules.
@@ -119,7 +116,6 @@ $(modules:.ko=.mod.o): %.mod.o: %.mod.c FORCE
targets += $(modules:.ko=.mod.o)
# Step 6), final link of the modules
-ifneq ($(CONFIG_MODULE_SIG),y)
quiet_cmd_ld_ko_o = LD [M] $@
cmd_ld_ko_o = $(LD) -r $(LDFLAGS) \
$(KBUILD_LDFLAGS_MODULE) $(LDFLAGS_MODULE) \
@@ -129,78 +125,7 @@ $(modules): %.ko :%.o %.mod.o FORCE
$(call if_changed,ld_ko_o)
targets += $(modules)
-else
-quiet_cmd_ld_ko_unsigned_o = LD [M] $@
- cmd_ld_ko_unsigned_o = \
- $(LD) -r $(LDFLAGS) \
- $(KBUILD_LDFLAGS_MODULE) $(LDFLAGS_MODULE) \
- -o $@ $(filter-out FORCE,$^) \
- $(if $(AFTER_LINK),; $(AFTER_LINK))
-
-$(modules:.ko=.ko.unsigned): %.ko.unsigned :%.o %.mod.o FORCE
- $(call if_changed,ld_ko_unsigned_o)
-
-targets += $(modules:.ko=.ko.unsigned)
-
-# Step 7), sign the modules
-MODSECKEY = ./signing_key.priv
-MODPUBKEY = ./signing_key.x509
-
-ifeq ($(wildcard $(MODSECKEY))+$(wildcard $(MODPUBKEY)),$(MODSECKEY)+$(MODPUBKEY))
-ifeq ($(KBUILD_SRC),)
- # no O= is being used
- SCRIPTS_DIR := scripts
-else
- SCRIPTS_DIR := $(KBUILD_SRC)/scripts
-endif
-SIGN_MODULES := 1
-else
-SIGN_MODULES := 0
-endif
-
-# only sign if it's an in-tree module
-ifneq ($(KBUILD_EXTMOD),)
-SIGN_MODULES := 0
-endif
-# We strip the module as best we can - note that using both strip and eu-strip
-# results in a smaller module than using either alone.
-EU_STRIP = $(shell which eu-strip || echo true)
-
-quiet_cmd_sign_ko_stripped_ko_unsigned = STRIP [M] $@
- cmd_sign_ko_stripped_ko_unsigned = \
- cp $< $@ && \
- strip -x -g $@ && \
- $(EU_STRIP) $@
-
-ifeq ($(SIGN_MODULES),1)
-
-quiet_cmd_genkeyid = GENKEYID $@
- cmd_genkeyid = \
- perl $(SCRIPTS_DIR)/x509keyid $< $<.signer $<.keyid
-
-%.signer %.keyid: %
- $(call if_changed,genkeyid)
-
-KEYRING_DEP := $(MODSECKEY) $(MODPUBKEY) $(MODPUBKEY).signer $(MODPUBKEY).keyid
-quiet_cmd_sign_ko_ko_stripped = SIGN [M] $@
- cmd_sign_ko_ko_stripped = \
- sh $(SCRIPTS_DIR)/sign-file $(MODSECKEY) $(MODPUBKEY) $< $@
-else
-KEYRING_DEP :=
-quiet_cmd_sign_ko_ko_unsigned = NO SIGN [M] $@
- cmd_sign_ko_ko_unsigned = \
- cp $< $@
-endif
-
-$(modules): %.ko :%.ko.stripped $(KEYRING_DEP) FORCE
- $(call if_changed,sign_ko_ko_stripped)
-
-$(patsubst %.ko,%.ko.stripped,$(modules)): %.ko.stripped :%.ko.unsigned FORCE
- $(call if_changed,sign_ko_stripped_ko_unsigned)
-
-targets += $(modules)
-endif
# Add FORCE to the prequisites of a target to force it to be always rebuilt.
# ---------------------------------------------------------------------------
diff --git a/scripts/sign-file b/scripts/sign-file
index e58e34e..3084ba4 100644
--- a/scripts/sign-file
+++ b/scripts/sign-file
@@ -16,7 +16,7 @@ fi
key="$1"
x509="$2"
src="$3"
-dst="$4"
+dst="${4:-$3}"
if [ ! -r "$key" ]
then
On Wed, Oct 17, 2012 at 8:14 PM, Linus Torvalds
<[email protected]> wrote:
>
> Oh, yes, we should make sure the key file gets cleaned up at "make clean".
Ooh, double-checked.
Actually, we have documented "make clean" to leave around "enough
build support to build external modules".
So technically, I guess what we do right now is correct: you have to
do "make distclean" (or "mrproper") to clean the key files.
Now, whether we should perhaps change that (and change the
documentation), I dunno.
Linus
On Wed, Oct 17, 2012 at 6:17 PM, Rusty Russell <[email protected]> wrote:
>
> You cut too much: you need genkeyid.
Yeah, I sent out a fixed version later, but I much prefer your version
that generates those files earlier, not a "make modules_install".
[ Btw, your email "Date:" field is from 2+ hours ago, but it hit
ozlabs and then arrived here only minutes ago. There's some delay in
your mail delivery. Maybe it's something you know about, and you're
batching emails over carrier pigeons, but I thought I'd mention it in
case you weren't aware of some odd SMTP delay ]
> And in a moment of optimism I tried 'make modules_install MODLIB=.' to
> sign modules in-place. It deleted my kernel/ dir. Don't recommend.
Heh. I assume that's an old "feature", not something that has anything
to do with the whole signing thing.
Linus
Linus Torvalds <[email protected]> writes:
> On Wed, Oct 17, 2012 at 3:19 PM, David Howells <[email protected]> wrote:
>>
>> It's probably even better to just get rid of all the automatic module signing
>> stuff completely and leave the sign-file script for the builder to use
>> manually. The module verification code will still be present.
>
> That's just disgusting crazy talk.
>
> Christ, David, get a grip on yourself. You seem to dismiss the "people
> want to build their own kernel" people entirely.
>
> One of the main sane use-cases for module signing is:
>
> - CONFIG_CHECK_SIGNATURE=y
> - randomly generated one-time key
> - "make modules_install; make install"
> - "make clean" to get rid of the keys.
> - reboot.
>
> and now you have a custom kernel that has the convenience of modules,
> yet is basically as safe as a non-modular build. The above makes it
> much harder for any kind of root-kit module to be loaded, and
> basically entirely avoids one fundamental security scare of modules.
If you only want this, we could SHA all the built modules, put that in
the kernel, and verify the module being loaded matches one of them.
Sure, it means a bit of trickery to get the module sums into the
bzImage, but the rest is trivial.
Cheers,
Rusty.
Linus Torvalds <[email protected]> writes:
> Ta-daa, you have your debuginfo modules installed, and they are
> signed. Create the debuginfo rpm.
>
> - now, strip the modules. This obviously destroys the signatures
Note this doesn't remove them. You'll need something like:
dd if=$k of=$k.nosig bs=$(grep -cba $k '~Module signature appended~' | cut -d: -f1) count=1 && mv $k.nosig $k
Cheers,
Rusty.
Linus Torvalds <[email protected]> writes:
> On Wed, Oct 17, 2012 at 5:54 PM, Greg KH <[email protected]> wrote:
>>>
>>> One of the main sane use-cases for module signing is:
>>>
>>> - CONFIG_CHECK_SIGNATURE=y
>>> - randomly generated one-time key
>>> - "make modules_install; make install"
>>> - "make clean" to get rid of the keys.
>>> - reboot.
>>
>> I want that too, but right now 'make clean' leaves the keys around,
>> which seems a bit dangerous to me.
>
> Oh, yes, we should make sure the key file gets cleaned up at "make clean".
I left it at distclean, figuring the temporary key is a bit like the
.config. But it's trivial to change if people think that's unnatural.
Cheers,
Rusty.
Linus Torvalds <[email protected]> writes:
> On Wed, Oct 17, 2012 at 6:17 PM, Rusty Russell <[email protected]> wrote:
>>
>> You cut too much: you need genkeyid.
>
> Yeah, I sent out a fixed version later, but I much prefer your version
> that generates those files earlier, not a "make modules_install".
Still committing a minor crime by lying to make about dependencies...
Hacking the keyid and signer-name to be extracted every time by
sign-file takes my modules_install time from 18.6 seconds to 19.1. We'd
get that back easily by making sign-file a perl script anyway; it calls
out to perl 3 times already.
David, want to take that on? My perl skills are lame, as shown below.
> [ Btw, your email "Date:" field is from 2+ hours ago, but it hit
> ozlabs and then arrived here only minutes ago. There's some delay in
> your mail delivery. Maybe it's something you know about, and you're
> batching emails over carrier pigeons, but I thought I'd mention it in
> case you weren't aware of some odd SMTP delay ]
I rsync mail to/from ozlabs.org. Manually, to avoid the
distraction-trickle. I could cron the outoing.
It's let me revoke unsent mail a few times. But maybe it's time to
embrace my uncanny ability to make a fool of myself? So many hackers
seem to revel in it, and they're nowhere as accomplished at it as I
am...
>> And in a moment of optimism I tried 'make modules_install MODLIB=.' to
>> sign modules in-place. It deleted my kernel/ dir. Don't recommend.
>
> Heh. I assume that's an old "feature", not something that has anything
> to do with the whole signing thing.
Exactly. But would have a been a nice hack for in-place signing.
A separate (optional) module_sign target seems easier.
Cheers,
Rusty.
diff --git a/kernel/Makefile b/kernel/Makefile
index f7abe6c..0bfd665 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -139,13 +139,7 @@ ifeq ($(CONFIG_MODULE_SIG),y)
extra_certificates:
touch $@
-quiet_cmd_genkeyid = GENKEYID $@
- cmd_genkeyid = $(PERL) $(src)/x509keyid.pl $< $<.signer $<.keyid
-
-%.signer %.keyid: %
- $(call if_changed,genkeyid)
-
-kernel/modsign_pubkey.o: signing_key.x509 extra_certificates $(MODPUBKEY).signer $(MODPUBKEY).keyid
+kernel/modsign_pubkey.o: signing_key.x509 extra_certificates
###############################################################################
diff --git a/kernel/x509keyid.pl b/kernel/x509keyid.pl
index c8e91a4..4241ec6 100755
--- a/kernel/x509keyid.pl
+++ b/kernel/x509keyid.pl
@@ -22,7 +22,7 @@ use strict;
my $raw_data;
-die "Need three filenames\n" if ($#ARGV != 2);
+die "Need a filename [keyid|signer-name]\n" if ($#ARGV != 1);
my $src = $ARGV[0];
@@ -259,10 +259,10 @@ die $src, ": ", "X.509: Couldn't find the Subject Key Identifier extension\n"
my $id_key_id = asn1_retrieve($subject_key_id->[1]);
-open(OUTFD, ">$ARGV[1]") || die $ARGV[1];
-print OUTFD $id_name;
-close OUTFD || die $ARGV[1];
-
-open(OUTFD, ">$ARGV[2]") || die $ARGV[2];
-print OUTFD $id_key_id;
-close OUTFD || die $ARGV[2];
+if ($ARGV[1] eq "signer-name") {
+ print $id_name;
+} elsif ($ARGV[1] eq "keyid") {
+ print $id_key_id;
+} else {
+ die "Unknown arg";
+}
diff --git a/scripts/sign-file b/scripts/sign-file
index 3084ba4..ea76f43 100644
--- a/scripts/sign-file
+++ b/scripts/sign-file
@@ -1,4 +1,4 @@
-#!/bin/sh
+#!/bin/bash
#
# Sign a module file using the given key.
#
@@ -29,16 +29,6 @@ then
echo "Can't read X.509 certificate" >&2
exit 2
fi
-if [ ! -r "$x509.signer" ]
-then
- echo "Can't read Signer name" >&2
- exit 2;
-fi
-if [ ! -r "$x509.keyid" ]
-then
- echo "Can't read Key identifier" >&2
- exit 2;
-fi
#
# Signature parameters
@@ -91,9 +81,11 @@ openssl dgst $dgst -binary $src || exit $?
# the signature with no metadata attached.
#
openssl rsautl -sign -inkey $key -keyform PEM -in $src.dig -out $src.sig || exit $?
-signerlen=`stat -c %s $x509.signer`
-keyidlen=`stat -c %s $x509.keyid`
-siglen=`stat -c %s $src.sig`
+
+SIGNER="`perl kernel/x509keyid.pl $x509 signer-name`"
+KEYID="`perl kernel/x509keyid.pl $x509 keyid`"
+keyidlen=${#KEYID}
+siglen=${#SIGNER}
#
# Build the signed binary
@@ -101,7 +93,8 @@ siglen=`stat -c %s $src.sig`
(
cat $src || exit $?
echo '~Module signature appended~' || exit $?
- cat $x509.signer $x509.keyid || exit $?
+ echo -n "$SIGNER" || exit $?
+ echo -n "$KEYID" || exit $?
# Preface each signature integer with a 2-byte BE length
perl -e "binmode STDOUT; print pack(\"n\", $siglen)" || exit $?
On Thu, Oct 18, 2012 at 03:01:08PM +1030, Rusty Russell wrote:
> Linus Torvalds <[email protected]> writes:
> > On Wed, Oct 17, 2012 at 3:19 PM, David Howells <[email protected]> wrote:
> >>
> >> It's probably even better to just get rid of all the automatic module signing
> >> stuff completely and leave the sign-file script for the builder to use
> >> manually. The module verification code will still be present.
> >
> > That's just disgusting crazy talk.
> >
> > Christ, David, get a grip on yourself. You seem to dismiss the "people
> > want to build their own kernel" people entirely.
> >
> > One of the main sane use-cases for module signing is:
> >
> > - CONFIG_CHECK_SIGNATURE=y
> > - randomly generated one-time key
> > - "make modules_install; make install"
> > - "make clean" to get rid of the keys.
> > - reboot.
> >
> > and now you have a custom kernel that has the convenience of modules,
> > yet is basically as safe as a non-modular build. The above makes it
> > much harder for any kind of root-kit module to be loaded, and
> > basically entirely avoids one fundamental security scare of modules.
>
> If you only want this, we could SHA all the built modules, put that in
> the kernel, and verify the module being loaded matches one of them.
>
> Sure, it means a bit of trickery to get the module sums into the
> bzImage, but the rest is trivial.
It also excludes out-of-tree drivers. I wouldn't personally shed a tear
for them, but it eliminates a use-case that people could have if we just
stuck to the signed module approach.
I'd prefer if we just cleaned up what we already have.
josh
On Thu, Oct 18, 2012 at 5:11 AM, Josh Boyer <[email protected]> wrote:
>
> It also excludes out-of-tree drivers. I wouldn't personally shed a tear
> for them, but it eliminates a use-case that people could have if we just
> stuck to the signed module approach.
>
> I'd prefer if we just cleaned up what we already have.
Exactly. I think the advantage of module signing is that it allows for
many different use-cases. People who care deeply about security can do
the "sign modules at kernel compile time with a one-time random key
that gets removed", and simply always reject anything else. And maybe
corporate users want something similar for corporate laptops.
And then vendors can do the "sign stuff with vendor key, and print big
warning and/or taint the kernel if loading unsigned modules" so that
people can at least validate the "standard" modules or something.
So signing is the nice flexible option, and technically the right
thing to do. I just want to make sure that what we make the *easy*
thing to do with that flexible option is the nice sane
GoodSecurity(tm) thing. If somebody wants to do something else with
it, fine, but it's not what the primary objective of the makefile
rules should be about.
I like how the default makefiles do that "create and use random key"
thing by default. THAT is what I want to see.
(Side note: I hope people realize that the random key is generated
with a 100-year lifespan. So if you build a kernel today, you do
potentially have a "year-2112 problem". I'm not horribly worried, but
I *am* a bit worried about 32-bit time_t overflow and I hope 32-bit
openssl doesn't do anything odd)
Linus
On Thu, Oct 18, 2012 at 03:04:26PM +1030, Rusty Russell wrote:
> Linus Torvalds <[email protected]> writes:
> > On Wed, Oct 17, 2012 at 5:54 PM, Greg KH <[email protected]> wrote:
> >>>
> >>> One of the main sane use-cases for module signing is:
> >>>
> >>> - CONFIG_CHECK_SIGNATURE=y
> >>> - randomly generated one-time key
> >>> - "make modules_install; make install"
> >>> - "make clean" to get rid of the keys.
> >>> - reboot.
> >>
> >> I want that too, but right now 'make clean' leaves the keys around,
> >> which seems a bit dangerous to me.
> >
> > Oh, yes, we should make sure the key file gets cleaned up at "make clean".
>
> I left it at distclean, figuring the temporary key is a bit like the
> .config. But it's trivial to change if people think that's unnatural.
.config is user-generated, while the key is build-generated. I assumed
that 'make clean' would clean up anything the build created, but as
Linus points out, the docs say that we will have enough stuff around to
build a module, so I guess it makes sense in that case.
Oh, along those lines, should the keys really end up in the root of the
kernel source tree? keys/ perhaps? But this is really just
bikesheding, that's up to you and David, it's not my code to maintain :)
thanks,
greg k-h
On Wed, Oct 17, 2012 at 10:34 PM, Rusty Russell <[email protected]> wrote:
>
> Hacking the keyid and signer-name to be extracted every time by
> sign-file takes my modules_install time from 18.6 seconds to 19.1. We'd
> get that back easily by making sign-file a perl script anyway; it calls
> out to perl 3 times already.
Ok, that tiny slowdown seems worth the cleanup, especially if we'd get
it back from somebody re-writing it in perl.
Want to sign off on the two patches, or put them in your git tree?
Linus
On Thu, Oct 18, 2012 at 2:46 PM, Linus Torvalds
<[email protected]> wrote:
> On Wed, Oct 17, 2012 at 10:34 PM, Rusty Russell <[email protected]> wrote:
>>
>> Hacking the keyid and signer-name to be extracted every time by
>> sign-file takes my modules_install time from 18.6 seconds to 19.1. We'd
>> get that back easily by making sign-file a perl script anyway; it calls
>> out to perl 3 times already.
>
> Ok, that tiny slowdown seems worth the cleanup, especially if we'd get
> it back from somebody re-writing it in perl.
>
> Want to sign off on the two patches, or put them in your git tree?
I tested Rusty's version of the 'sign modules at module_install time'
patch in a Fedora kernel build today. It seems to work well enough,
even if we wind up signing things twice. A brief cleanup of my patch
to add a modules_sign target on top of that is below.
It might even be able to be moved entirely into scripts/Makefile.modinst
but I haven't gotten that far yet.
josh
---
>From d83055aec38e5717957e621d94fff67241ef803d Mon Sep 17 00:00:00 2001
From: Josh Boyer <[email protected]>
Date: Mon, 24 Sep 2012 10:46:36 -0400
Subject: [PATCH] MODSIGN: Add modules_sign make target
If CONFIG_MODULE_SIG is set, and 'make modules_sign' is called then this
patch will cause the modules to get a signature appended. The make target
is intended to be run after 'make modules_install', and will modify the
modules in-place in the installed location. It can be used to produce
signed modules after they have been processed by distribution build
scripts.
Signed-off-by: Josh Boyer <[email protected]>
---
Makefile | 6 ++++++
scripts/Makefile.modsign | 32 ++++++++++++++++++++++++++++++++
2 files changed, 38 insertions(+)
create mode 100644 scripts/Makefile.modsign
diff --git a/Makefile b/Makefile
index 89a2e2c..ac04c11 100644
--- a/Makefile
+++ b/Makefile
@@ -981,6 +981,12 @@ _modinst_post: _modinst_
$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.fwinst obj=firmware __fw_modinst
$(call cmd,depmod)
+ifeq ($(CONFIG_MODULE_SIG), y)
+PHONY += modules_sign
+modules_sign:
+ $(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modsign
+endif
+
else # CONFIG_MODULES
# Modules not configured
diff --git a/scripts/Makefile.modsign b/scripts/Makefile.modsign
new file mode 100644
index 0000000..670d5dc
--- /dev/null
+++ b/scripts/Makefile.modsign
@@ -0,0 +1,32 @@
+# ==========================================================================
+# Signing modules
+# ==========================================================================
+
+PHONY := __modsign
+__modsign:
+
+include scripts/Kbuild.include
+
+__modules := $(sort $(shell grep -h '\.ko' /dev/null $(wildcard
$(MODVERDIR)/*.mod)))
+modules := $(patsubst %.o,%.ko,$(wildcard $(__modules:.ko=.o)))
+
+PHONY += $(modules)
+__modsign: $(modules)
+ @:
+
+quiet_cmd_sign_ko = SIGN [M] $(2)/$(notdir $@)
+ cmd_sign_ko = $(mod_sign_cmd) $(2)/$(notdir $@)
+
+# Modules built outside the kernel source tree go into extra by default
+INSTALL_MOD_DIR ?= extra
+ext-mod-dir = $(INSTALL_MOD_DIR)$(subst $(patsubst
%/,%,$(KBUILD_EXTMOD)),,$(@D))
+
+modinst_dir = $(if $(KBUILD_EXTMOD),$(ext-mod-dir),kernel/$(@D))
+
+$(modules):
+ $(call cmd,sign_ko,$(MODLIB)/$(modinst_dir))
+
+# Declare the contents of the .PHONY variable as phony. We keep that
+# # information in a variable se we can use it in if_changed and friends.
+
+.PHONY: $(PHONY)
--
1.7.12.1
The micturator of the Holy Penguin Pee spake:
> (Side note: I hope people realize that the random key is generated
> with a 100-year lifespan. So if you build a kernel today, you do
> potentially have a "year-2112 problem". I'm not horribly worried, but
> I *am* a bit worried about 32-bit time_t overflow and I hope 32-bit
> openssl doesn't do anything odd)
Well, the kernel uses time_t, which should be >= 64 bits on any machine
still operational outside the computer history museum at that time.
But it also allows an expiry time of 0 to indicate "no expiration".
It's worth noting that in X.509 *keys* don't have expirations; only
*certifications* do. That is, the signature binding a name to the key.
You can issue any number of certificates, with different expiration dates,
on the same key.
(The only reason that there's this "certificate = key" confusion
is that X.509 doesn't specify a format for a bare key, so the
certificate format is also used as a key container.)
I haven't figured out the kernel key loading procedure, but it's not
clear that it even sets the expiry time. It does not, for example,
have any equivalent to the X.509 validity start time, so it wasn't
designed with importing certificates in mind.
Even if it is set, you could disable expiration checking on key lookup
and not care about expiration dates. (Pass no_state_check=true as the
last argument to keyring_search_aux.)
Linus Torvalds <[email protected]> writes:
> So signing is the nice flexible option, and technically the right
> thing to do.
Meh.... It's 52k of extra text to get that 'nice flexible'; 1% of my
kernel image. That's a lot of bug free code.
> (Side note: I hope people realize that the random key is generated
> with a 100-year lifespan. So if you build a kernel today, you do
> potentially have a "year-2112 problem". I'm not horribly worried, but
> I *am* a bit worried about 32-bit time_t overflow and I hope 32-bit
> openssl doesn't do anything odd)
Yep, David's original patch had that problem; he fixed the kernel's x509
handling to use struct tm, not time_t, and now it Just Works.
Cheers,
Rusty.
Josh Boyer <[email protected]> writes:
> It might even be able to be moved entirely into scripts/Makefile.modinst
> but I haven't gotten that far yet.
Thanks, I'll add this.
Note it was word-wrapped here though :(
Cheers,
Rusty.
Josh Boyer <[email protected]> writes:
> On Thu, Oct 18, 2012 at 2:46 PM, Linus Torvalds
> <[email protected]> wrote:
>> On Wed, Oct 17, 2012 at 10:34 PM, Rusty Russell <[email protected]> wrote:
>>>
>>> Hacking the keyid and signer-name to be extracted every time by
>>> sign-file takes my modules_install time from 18.6 seconds to 19.1. We'd
>>> get that back easily by making sign-file a perl script anyway; it calls
>>> out to perl 3 times already.
>>
>> Ok, that tiny slowdown seems worth the cleanup, especially if we'd get
>> it back from somebody re-writing it in perl.
>>
>> Want to sign off on the two patches, or put them in your git tree?
>
> I tested Rusty's version of the 'sign modules at module_install time'
> patch in a Fedora kernel build today. It seems to work well enough,
> even if we wind up signing things twice. A brief cleanup of my patch
> to add a modules_sign target on top of that is below.
I'm surprised. Only the first signature (create on the unstripped
module) will be used by the kernel; this should fail to verify the
stripped module. A quick and dirty check is:
grep -abo '~Module' /tmp/mod/lib/modules/3.7.0-rc1+/kernel/sound/pci/snd-intel8x0.ko
39828:~Module
40432:~Module
Perhaps eu-strip actually strips the appended signature?
> It might even be able to be moved entirely into scripts/Makefile.modinst
> but I haven't gotten that far yet.
I'll leave this for the moment.
Cheers,
Rusty.
Linus Torvalds <[email protected]> writes:
> On Wed, Oct 17, 2012 at 10:34 PM, Rusty Russell <[email protected]> wrote:
>>
>> Hacking the keyid and signer-name to be extracted every time by
>> sign-file takes my modules_install time from 18.6 seconds to 19.1. We'd
>> get that back easily by making sign-file a perl script anyway; it calls
>> out to perl 3 times already.
>
> Ok, that tiny slowdown seems worth the cleanup, especially if we'd get
> it back from somebody re-writing it in perl.
>
> Want to sign off on the two patches, or put them in your git tree?
Smerged them together: no point moving the x509keyid script now.
I dropped the optional dst arg, since we don't use it.
Thanks,
Rusty.
===
From: Rusty Russell <[email protected]>
Subject: [PATCH] kbuild: sign the modules at install time
Linus deleted the old code and put signing on the install command,
I fixed it to extract the keyid and signer-name within sign-file
and cleaned up that script now it always signs in-place.
Some enthusiast should convert sign-key to perl and pull
x509keyid into it.
Signed-off-by: Rusty Russell <[email protected]>
diff --git a/Makefile b/Makefile
index 5be2ee8..8efe41d 100644
--- a/Makefile
+++ b/Makefile
@@ -717,6 +717,17 @@ endif # INSTALL_MOD_STRIP
export mod_strip_cmd
+ifeq ($(CONFIG_MODULE_SIG),y)
+MODSECKEY = ./signing_key.priv
+MODPUBKEY = ./signing_key.x509
+export MODPUBKEY
+mod_sign_cmd = sh $(srctree)/scripts/sign-file $(MODSECKEY) $(MODPUBKEY) $(srctree)/scripts/x509keyid
+else
+mod_sign_cmd = true
+endif
+export mod_sign_cmd
+
+
ifeq ($(KBUILD_EXTMOD),)
core-y += kernel/ mm/ fs/ ipc/ security/ crypto/ block/
diff --git a/scripts/Makefile.modinst b/scripts/Makefile.modinst
index 3d13d3a..dda4b2b 100644
--- a/scripts/Makefile.modinst
+++ b/scripts/Makefile.modinst
@@ -17,7 +17,7 @@ __modinst: $(modules)
@:
quiet_cmd_modules_install = INSTALL $@
- cmd_modules_install = mkdir -p $(2); cp $@ $(2) ; $(mod_strip_cmd) $(2)/$(notdir $@)
+ cmd_modules_install = mkdir -p $(2); cp $@ $(2) ; $(mod_strip_cmd) $(2)/$(notdir $@) ; $(mod_sign_cmd) $(2)/$(notdir $@)
# Modules built outside the kernel source tree go into extra by default
INSTALL_MOD_DIR ?= extra
diff --git a/scripts/Makefile.modpost b/scripts/Makefile.modpost
index 0020891..a1cb022 100644
--- a/scripts/Makefile.modpost
+++ b/scripts/Makefile.modpost
@@ -14,8 +14,7 @@
# 3) create one <module>.mod.c file pr. module
# 4) create one Module.symvers file with CRC for all exported symbols
# 5) compile all <module>.mod.c files
-# 6) final link of the module to a <module.ko> (or <module.unsigned>) file
-# 7) signs the modules to a <module.ko> file
+# 6) final link of the module to a <module.ko> file
# Step 3 is used to place certain information in the module's ELF
# section, including information such as:
@@ -33,8 +32,6 @@
# Step 4 is solely used to allow module versioning in external modules,
# where the CRC of each module is retrieved from the Module.symvers file.
-# Step 7 is dependent on CONFIG_MODULE_SIG being enabled.
-
# KBUILD_MODPOST_WARN can be set to avoid error out in case of undefined
# symbols in the final module linking stage
# KBUILD_MODPOST_NOFINAL can be set to skip the final link of modules.
@@ -119,7 +116,6 @@ $(modules:.ko=.mod.o): %.mod.o: %.mod.c FORCE
targets += $(modules:.ko=.mod.o)
# Step 6), final link of the modules
-ifneq ($(CONFIG_MODULE_SIG),y)
quiet_cmd_ld_ko_o = LD [M] $@
cmd_ld_ko_o = $(LD) -r $(LDFLAGS) \
$(KBUILD_LDFLAGS_MODULE) $(LDFLAGS_MODULE) \
@@ -129,78 +125,7 @@ $(modules): %.ko :%.o %.mod.o FORCE
$(call if_changed,ld_ko_o)
targets += $(modules)
-else
-quiet_cmd_ld_ko_unsigned_o = LD [M] $@
- cmd_ld_ko_unsigned_o = \
- $(LD) -r $(LDFLAGS) \
- $(KBUILD_LDFLAGS_MODULE) $(LDFLAGS_MODULE) \
- -o $@ $(filter-out FORCE,$^) \
- $(if $(AFTER_LINK),; $(AFTER_LINK))
-
-$(modules:.ko=.ko.unsigned): %.ko.unsigned :%.o %.mod.o FORCE
- $(call if_changed,ld_ko_unsigned_o)
-
-targets += $(modules:.ko=.ko.unsigned)
-
-# Step 7), sign the modules
-MODSECKEY = ./signing_key.priv
-MODPUBKEY = ./signing_key.x509
-
-ifeq ($(wildcard $(MODSECKEY))+$(wildcard $(MODPUBKEY)),$(MODSECKEY)+$(MODPUBKEY))
-ifeq ($(KBUILD_SRC),)
- # no O= is being used
- SCRIPTS_DIR := scripts
-else
- SCRIPTS_DIR := $(KBUILD_SRC)/scripts
-endif
-SIGN_MODULES := 1
-else
-SIGN_MODULES := 0
-endif
-
-# only sign if it's an in-tree module
-ifneq ($(KBUILD_EXTMOD),)
-SIGN_MODULES := 0
-endif
-# We strip the module as best we can - note that using both strip and eu-strip
-# results in a smaller module than using either alone.
-EU_STRIP = $(shell which eu-strip || echo true)
-
-quiet_cmd_sign_ko_stripped_ko_unsigned = STRIP [M] $@
- cmd_sign_ko_stripped_ko_unsigned = \
- cp $< $@ && \
- strip -x -g $@ && \
- $(EU_STRIP) $@
-
-ifeq ($(SIGN_MODULES),1)
-
-quiet_cmd_genkeyid = GENKEYID $@
- cmd_genkeyid = \
- perl $(SCRIPTS_DIR)/x509keyid $< $<.signer $<.keyid
-
-%.signer %.keyid: %
- $(call if_changed,genkeyid)
-
-KEYRING_DEP := $(MODSECKEY) $(MODPUBKEY) $(MODPUBKEY).signer $(MODPUBKEY).keyid
-quiet_cmd_sign_ko_ko_stripped = SIGN [M] $@
- cmd_sign_ko_ko_stripped = \
- sh $(SCRIPTS_DIR)/sign-file $(MODSECKEY) $(MODPUBKEY) $< $@
-else
-KEYRING_DEP :=
-quiet_cmd_sign_ko_ko_unsigned = NO SIGN [M] $@
- cmd_sign_ko_ko_unsigned = \
- cp $< $@
-endif
-
-$(modules): %.ko :%.ko.stripped $(KEYRING_DEP) FORCE
- $(call if_changed,sign_ko_ko_stripped)
-
-$(patsubst %.ko,%.ko.stripped,$(modules)): %.ko.stripped :%.ko.unsigned FORCE
- $(call if_changed,sign_ko_stripped_ko_unsigned)
-
-targets += $(modules)
-endif
# Add FORCE to the prequisites of a target to force it to be always rebuilt.
# ---------------------------------------------------------------------------
diff --git a/scripts/sign-file b/scripts/sign-file
index e58e34e..095a953 100644
--- a/scripts/sign-file
+++ b/scripts/sign-file
@@ -1,8 +1,8 @@
-#!/bin/sh
+#!/bin/bash
#
# Sign a module file using the given key.
#
-# Format: sign-file <key> <x509> <src-file> <dst-file>
+# Format: sign-file <key> <x509> <keyid-script> <module>
#
scripts=`dirname $0`
@@ -15,8 +15,8 @@ fi
key="$1"
x509="$2"
-src="$3"
-dst="$4"
+keyid_script="$3"
+mod="$4"
if [ ! -r "$key" ]
then
@@ -29,16 +29,6 @@ then
echo "Can't read X.509 certificate" >&2
exit 2
fi
-if [ ! -r "$x509.signer" ]
-then
- echo "Can't read Signer name" >&2
- exit 2;
-fi
-if [ ! -r "$x509.keyid" ]
-then
- echo "Can't read Key identifier" >&2
- exit 2;
-fi
#
# Signature parameters
@@ -83,33 +73,35 @@ fi
(
perl -e "binmode STDOUT; print pack(\"C*\", $prologue)" || exit $?
-openssl dgst $dgst -binary $src || exit $?
-) >$src.dig || exit $?
+openssl dgst $dgst -binary $mod || exit $?
+) >$mod.dig || exit $?
#
# Generate the binary signature, which will be just the integer that comprises
# the signature with no metadata attached.
#
-openssl rsautl -sign -inkey $key -keyform PEM -in $src.dig -out $src.sig || exit $?
-signerlen=`stat -c %s $x509.signer`
-keyidlen=`stat -c %s $x509.keyid`
-siglen=`stat -c %s $src.sig`
+openssl rsautl -sign -inkey $key -keyform PEM -in $mod.dig -out $mod.sig || exit $?
+
+SIGNER="`perl $keyid_script $x509 signer-name`"
+KEYID="`perl $keyid_script $x509 keyid`"
+keyidlen=${#KEYID}
+siglen=${#SIGNER}
#
# Build the signed binary
#
(
- cat $src || exit $?
+ cat $mod || exit $?
echo '~Module signature appended~' || exit $?
- cat $x509.signer $x509.keyid || exit $?
+ echo -n "$SIGNER" || exit $?
+ echo -n "$KEYID" || exit $?
# Preface each signature integer with a 2-byte BE length
perl -e "binmode STDOUT; print pack(\"n\", $siglen)" || exit $?
- cat $src.sig || exit $?
+ cat $mod.sig || exit $?
# Generate the information block
perl -e "binmode STDOUT; print pack(\"CCCCCxxxN\", $algo, $hash, $id_type, $signerlen, $keyidlen, $siglen + 2)" || exit $?
-) >$dst~ || exit $?
+) >$mod~ || exit $?
-# Permit in-place signing
-mv $dst~ $dst || exit $?
+mv $mod~ $mod || exit $?
diff --git a/scripts/x509keyid b/scripts/x509keyid
index c8e91a4..4241ec6 100755
--- a/scripts/x509keyid
+++ b/scripts/x509keyid
@@ -22,7 +22,7 @@ use strict;
my $raw_data;
-die "Need three filenames\n" if ($#ARGV != 2);
+die "Need a filename [keyid|signer-name]\n" if ($#ARGV != 1);
my $src = $ARGV[0];
@@ -259,10 +259,10 @@ die $src, ": ", "X.509: Couldn't find the Subject Key Identifier extension\n"
my $id_key_id = asn1_retrieve($subject_key_id->[1]);
-open(OUTFD, ">$ARGV[1]") || die $ARGV[1];
-print OUTFD $id_name;
-close OUTFD || die $ARGV[1];
-
-open(OUTFD, ">$ARGV[2]") || die $ARGV[2];
-print OUTFD $id_key_id;
-close OUTFD || die $ARGV[2];
+if ($ARGV[1] eq "signer-name") {
+ print $id_name;
+} elsif ($ARGV[1] eq "keyid") {
+ print $id_key_id;
+} else {
+ die "Unknown arg";
+}
Hi Rusty,
On Fri, 19 Oct 2012 11:53:15 +1030 Rusty Russell <[email protected]> wrote:
>
> Linus Torvalds <[email protected]> writes:
> > On Wed, Oct 17, 2012 at 10:34 PM, Rusty Russell <[email protected]> wrote:
> >>
> >> Hacking the keyid and signer-name to be extracted every time by
> >> sign-file takes my modules_install time from 18.6 seconds to 19.1. We'd
> >> get that back easily by making sign-file a perl script anyway; it calls
> >> out to perl 3 times already.
> >
> > Ok, that tiny slowdown seems worth the cleanup, especially if we'd get
> > it back from somebody re-writing it in perl.
> >
> > Want to sign off on the two patches, or put them in your git tree?
>
> Smerged them together: no point moving the x509keyid script now.
> I dropped the optional dst arg, since we don't use it.
So, this still generates the keys during the normal build, right? That
would be a problem for build servers that have limited randomness
available to them, I think.
--
Cheers,
Stephen Rothwell [email protected]
Rusty Russell <[email protected]> wrote:
> > (Side note: I hope people realize that the random key is generated
> > with a 100-year lifespan. So if you build a kernel today, you do
> > potentially have a "year-2112 problem". I'm not horribly worried, but
> > I *am* a bit worried about 32-bit time_t overflow and I hope 32-bit
> > openssl doesn't do anything odd)
>
> Yep, David's original patch had that problem; he fixed the kernel's x509
> handling to use struct tm, not time_t, and now it Just Works.
That's assuming that 32-bit *openssl* gets it right when generating the key.
Trying it on my 32-bit laptop, I see:
154:d=3 hl=2 l= 15 prim: GENERALIZEDTIME :21120925112014Z
so I guess it does.
David
Stephen Rothwell <[email protected]> wrote:
> So, this still generates the keys during the normal build, right? That
> would be a problem for build servers that have limited randomness
> available to them, I think.
openssl uses /dev/urandom (unlike gpg), so that's less of a problem.
David
Hi David,
On Fri, 19 Oct 2012 12:25:23 +0100 David Howells <[email protected]> wrote:
>
> Stephen Rothwell <[email protected]> wrote:
>
> > So, this still generates the keys during the normal build, right? That
> > would be a problem for build servers that have limited randomness
> > available to them, I think.
>
> openssl uses /dev/urandom (unlike gpg), so that's less of a problem.
OK, thanks.
--
Cheers,
Stephen Rothwell [email protected]
Am 19.10.2012 13:25, schrieb David Howells:
> Stephen Rothwell <[email protected]> wrote:
>
>> So, this still generates the keys during the normal build, right? That
>> would be a problem for build servers that have limited randomness
>> available to them, I think.
>
> openssl uses /dev/urandom (unlike gpg), so that's less of a problem.
Hmm, please don't forget the case where people want to build the kernel
in some sandbox (like chroot or similiar) where the build-system doesn't
have access to /dev.
I haven't checked what openssl does if that is the case, so maybe the
script which calls it should either offer a verbose error message for
that case, or should be prepared that openssl might fail because of a
missing /dev/urandom.
If that's already done, just ignore my email, I haven't read the
complete thread, sorry.
Regards,
Alexander
On Thu, Oct 18, 2012 at 8:48 PM, Rusty Russell <[email protected]> wrote:
> Josh Boyer <[email protected]> writes:
>> It might even be able to be moved entirely into scripts/Makefile.modinst
>> but I haven't gotten that far yet.
>
> Thanks, I'll add this.
Excellent.
> Note it was word-wrapped here though :(
Sigh. Sorry, Rusty. I thought I had gmail's kinks worked out.
josh
On Thu, Oct 18, 2012 at 9:16 PM, Rusty Russell <[email protected]> wrote:
> Josh Boyer <[email protected]> writes:
>> On Thu, Oct 18, 2012 at 2:46 PM, Linus Torvalds
>> <[email protected]> wrote:
>>> On Wed, Oct 17, 2012 at 10:34 PM, Rusty Russell <[email protected]> wrote:
>>>>
>>>> Hacking the keyid and signer-name to be extracted every time by
>>>> sign-file takes my modules_install time from 18.6 seconds to 19.1. We'd
>>>> get that back easily by making sign-file a perl script anyway; it calls
>>>> out to perl 3 times already.
>>>
>>> Ok, that tiny slowdown seems worth the cleanup, especially if we'd get
>>> it back from somebody re-writing it in perl.
>>>
>>> Want to sign off on the two patches, or put them in your git tree?
>>
>> I tested Rusty's version of the 'sign modules at module_install time'
>> patch in a Fedora kernel build today. It seems to work well enough,
>> even if we wind up signing things twice. A brief cleanup of my patch
>> to add a modules_sign target on top of that is below.
>
> I'm surprised. Only the first signature (create on the unstripped
> module) will be used by the kernel; this should fail to verify the
> stripped module. A quick and dirty check is:
>
> grep -abo '~Module' /tmp/mod/lib/modules/3.7.0-rc1+/kernel/sound/pci/snd-intel8x0.ko
> 39828:~Module
> 40432:~Module
>
> Perhaps eu-strip actually strips the appended signature?
Yes. The abbreviated flow chart is:
build
install (signed at install time now)
find-debuginfo.sh (eu-strip) which strips off the signature from above
modules_sign to put it back
You are certainly correct in that if I am building outside of RPM and
run modules_install followed by modules_sign, it will append a second
signature.
A further check could be done in scripts/Makefile.modsign to see if each
module is already signed and skip it if so. I can take a look at doing
that next week if people think it would be worthwhile.
josh
On Thu, Oct 18, 2012 at 6:23 PM, Rusty Russell <[email protected]> wrote:
>
> Smerged them together: no point moving the x509keyid script now.
> I dropped the optional dst arg, since we don't use it.
>
> Thanks,
> Rusty.
> ===
> From: Rusty Russell <[email protected]>
> Subject: [PATCH] kbuild: sign the modules at install time
>
> Linus deleted the old code and put signing on the install command,
> I fixed it to extract the keyid and signer-name within sign-file
> and cleaned up that script now it always signs in-place.
Ugh. That was horribly broken, and sadly I didn't notice until several
pulls later (I tend to try to compile-test much more often, but do
boot-tests only a couple of times a day).
You clearly hadn't tested that patch at all, the resulting signature
was broken in two independent and totally different ways.
Tssk. I fixed it up, and now it works-for-me(tm), but some perl person
probably really should try to make that sign-file and x509keyid merge.
My fix made the thing even slower, doing two extra "wc -c" invocations
since it can't do "${#..}" expansion due to the locale problem.
Linus
On Fri, Oct 19, 2012 at 12:58 PM, Linus Torvalds
<[email protected]> wrote:
>
> Tssk. I fixed it up, and now it works-for-me(tm), but some perl person
> probably really should try to make that sign-file and x509keyid merge.
> My fix made the thing even slower, doing two extra "wc -c" invocations
> since it can't do "${#..}" expansion due to the locale problem.
Hmm. I haven't seen this breakage personally yet, but looking more at
Rusty's last changes I'm pretty sure my fixes are potentially not
sufficient.
In particular, this line from Rusty's sign-file script simplification
makes me worry:
KEYID="`perl $keyid_script $x509 keyid`"
and the problem is that the 'keyid' is a binary blob.
And I'm pretty damn sure that assigning random binary data to shell
variables is going to break eventually. In particular, I tested NUL
characters, and bash is not happy about doing things like
a="`echo -en '\000'`"
and 'a' ends up empty, not containing a one-byte string containing a
NUL character. Not to mention that even if the shell were to handle
this correctly, if you do
echo -n "$a"
then even *if* the shell remembered that 'a' contains one NUL
character, when it then executes the 'echo' binary, that will
certainly not be able to handle it. With a built-in 'echo' it _could_
work, with an external one it fundamentally could not. NUL is special,
and terminates strings at execve(). You cannot have NUL bytes in
arguments.
Of course, I don't know the rules for x509 key id blobs. Maybe they
aren't allowed to contain NUL anyway?
Possible solutions:
- Linus is a worry-wart, and key id's never contain NUL.
- somebody with the appropriate perl-fu does the perl conversion, and
keeps it all in perl.
- somebody with (slightly less) perl-fu makes the x509 keyid_script
return a quoted string, so that we can save that *quoted* version for
the shell interatction (perhaps in a similar format that we now use
for the "prologue" variable, ie just a list of hex bytes)
otherwise we need to go back to putting the binary blob in a file
(which shell won't corrupt).
Rusty, David?
Linus
Stephen Rothwell <[email protected]> writes:
> Hi Rusty,
>
> On Fri, 19 Oct 2012 11:53:15 +1030 Rusty Russell <[email protected]> wrote:
>>
>> Linus Torvalds <[email protected]> writes:
>> > On Wed, Oct 17, 2012 at 10:34 PM, Rusty Russell <[email protected]> wrote:
>> >>
>> >> Hacking the keyid and signer-name to be extracted every time by
>> >> sign-file takes my modules_install time from 18.6 seconds to 19.1. We'd
>> >> get that back easily by making sign-file a perl script anyway; it calls
>> >> out to perl 3 times already.
>> >
>> > Ok, that tiny slowdown seems worth the cleanup, especially if we'd get
>> > it back from somebody re-writing it in perl.
>> >
>> > Want to sign off on the two patches, or put them in your git tree?
>>
>> Smerged them together: no point moving the x509keyid script now.
>> I dropped the optional dst arg, since we don't use it.
>
> So, this still generates the keys during the normal build, right? That
> would be a problem for build servers that have limited randomness
> available to them, I think.
Yes. You can either continue to disable module signatures, or copy some
pre-made keys in the toplevel: signing_key.priv and signing_key.x509.
Cheers,
Rusty.
Linus Torvalds <[email protected]> writes:
> I like how the default makefiles do that "create and use random key"
> thing by default. THAT is what I want to see.
Yes, however the key generation itself is horribly verbose and doesn't mix
very well with the output of a parallel build. Now that the modules are
signed at install time, presumably the key should be generated then as
well, and the output cleaned up to look like normal Kbuild messages (with
support for V=1 for the curious).
On Sat, Oct 20, 2012 at 9:41 AM, Romain Francoise <[email protected]> wrote:
>
> Yes, however the key generation itself is horribly verbose and doesn't mix
> very well with the output of a parallel build. Now that the modules are
> signed at install time, presumably the key should be generated then as
> well, and the output cleaned up to look like normal Kbuild messages (with
> support for V=1 for the curious).
No, the key needs to be built before the kernel is built, since the
public part (for verification) needs to be built into the kernel (and
we don't want to make "make install" complicated).
Making it less verbose is clearly an option, though. Right now I like
seeing it just to see when the key gets recreated and so people are
aware of it, but the excitement of that will certainly pall quickly
enough ;)
Linus
David Howells <[email protected]> writes:
> Rusty Russell <[email protected]> wrote:
>
>> > (Side note: I hope people realize that the random key is generated
>> > with a 100-year lifespan. So if you build a kernel today, you do
>> > potentially have a "year-2112 problem". I'm not horribly worried, but
>> > I *am* a bit worried about 32-bit time_t overflow and I hope 32-bit
>> > openssl doesn't do anything odd)
>>
>> Yep, David's original patch had that problem; he fixed the kernel's x509
>> handling to use struct tm, not time_t, and now it Just Works.
>
> That's assuming that 32-bit *openssl* gets it right when generating the key.
Yes, I am assuming that. What openssl did you think I ran on my 32-bit
kernel? :)
Cheers,
Rusty.
Linus Torvalds <[email protected]> writes:
> On Fri, Oct 19, 2012 at 12:58 PM, Linus Torvalds
> <[email protected]> wrote:
>>
>> Tssk. I fixed it up, and now it works-for-me(tm), but some perl person
>> probably really should try to make that sign-file and x509keyid merge.
>> My fix made the thing even slower, doing two extra "wc -c" invocations
>> since it can't do "${#..}" expansion due to the locale problem.
>
> Hmm. I haven't seen this breakage personally yet, but looking more at
> Rusty's last changes I'm pretty sure my fixes are potentially not
> sufficient.
Sorry for posting untested hack :(
Thanks for the rewrite David; modules_install here was 18.6 seconds,
became 19.1 with my broken hack, now 17.3 seconds.
Cheers,
Rusty.