All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Hutchings <ben@decadent.org.uk>
To: Lucas De Marchi <lucas.de.marchi@gmail.com>
Cc: linux-modules <linux-modules@vger.kernel.org>,
	820010@bugs.debian.org, Rusty Russell <rusty@rustcorp.com.au>
Subject: Re: [PATCH v2] libkmod: Add support for detached module signatures
Date: Tue, 17 May 2016 13:51:30 +0100	[thread overview]
Message-ID: <1463489490.8490.12.camel@decadent.org.uk> (raw)
In-Reply-To: <1460541612.2705.32.camel@decadent.org.uk>

[-- Attachment #1: Type: text/plain, Size: 3665 bytes --]

On Wed, 2016-04-13 at 11:00 +0100, Ben Hutchings wrote:
> On Wed, 2016-04-13 at 01:05 -0300, Lucas De Marchi wrote:
> > 
> > Hi,
> > 
> > CC'ing Rusty
> > 
> > On Mon, Apr 4, 2016 at 9:32 PM, Ben Hutchings <ben@decadent.org.uk> wrote:
> > > 
> > > 
> > > Debian will not sign modules during the kernel package build, as this
> > > conflicts with the goal of reproducible builds.  Instead, we will
> > > generate detached signatures offline and include them in a second
> > > package.
> > Is this a decision already? It doesn't look as a good reason - you
> > would already need to provide a signing key (CONFIG_MODULE_SIG_KEY)
> > anyway for this to work. How is leaving the module signature in
> > another package be any better than just signing the module?  If you
> > have the signature, the build is just as reproducible as before.
> I think we may have different ideas about what reproducibility means.
> When I say reproducible I mean *anyone* with the right tools installed
> can reproduce the binary packages (.deb) from the source package (.dsc
> and tarballs).
> 
> The signing key obviously isn't available to everyone, so the source
> package has to include detached signatures prepared outside of the
> package build process.  But we can't put them in the linux source
> package, because that results in a dependency loop.

So, given these requirements, what do you think now about supporting
detached signatures?

I spoke at greater length about what I'm trying to do at Linuxwochen
Wien; see
http://meetings-archive.debian.net/pub/debian-meetings/2016/mini-debconf-vienna/webm/Secure_Boot_vs_the_Debian_linux_package.webm#t=595
from about 9'55" to 17'30".

Ben.

> > 
> > > 
> > > 
> > > We could attach the signatures when building this second package or at
> > > installation time, but that leads to duplication of all modules,
> > > either in the archive or on users' systems.
> > > 
> > > To avoid this, add support to libkmod for concatenating modules with
> > > detached signatures (files with the '.sig' extension) at load time.
> > this has the drawback that finit_module() can't be used.
> So does module compression, but it's still a supported option.
> 
> [...]
> > 
> > > 
> > > +       /* Try to open a detached signature.  If it's missing, that's OK. */
> > > +       if (asprintf(&sig_filename, "%s.sig", filename) < 0) {
> > > +               err = -errno;
> > > +               goto error;
> > > +       }
> > > +       file->sig_fd = open(sig_filename, O_RDONLY|O_CLOEXEC);
> > > +       if (file->sig_fd < 0 && errno != ENOENT) {
> > > +               err = -errno;
> > > +               goto error;
> > > +       }
> > This can't really work if the module is being loaded uncompressed (I
> > think nowadays we can even add support for compressed modules...
> > Rusty, any input here?).
> > 
> > When the module is being directly loaded, the direct flag gets set so
> > kmod_module_insert_module() knows it can try to use finit_module().
> > Since you have an external signature what would happen is that we
> > would load the signature, but try to load the module in the kernel
> > without it.
> It does work.  I changed load_reg() to disable direct loading.when
> there's a detached signature.
> 
> Ben.
> 
> > 
> > I'm still not convinced the split module + signature is actually a good thing.
> > 
> > 
> > Lucas De Marchi
-- 
Ben Hutchings
Lowery's Law:
             If it jams, force it. If it breaks, it needed replacing anyway.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2016-05-17 12:51 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-05  0:16 [PATCH] libkmod: Add support for detached module signatures Ben Hutchings
2016-04-05  0:32 ` [PATCH v2] " Ben Hutchings
2016-04-13  4:05   ` Lucas De Marchi
2016-04-13 10:00     ` Ben Hutchings
2016-05-17 12:51       ` Ben Hutchings [this message]
2016-05-21 18:31       ` Lucas De Marchi
2016-05-21 18:40         ` Bug#820010: " Marco d'Itri
2016-05-21 19:01         ` Ben Hutchings
2016-05-29 12:48           ` Ben Hutchings
2016-06-04 14:13             ` Lucas De Marchi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1463489490.8490.12.camel@decadent.org.uk \
    --to=ben@decadent.org.uk \
    --cc=820010@bugs.debian.org \
    --cc=linux-modules@vger.kernel.org \
    --cc=lucas.de.marchi@gmail.com \
    --cc=rusty@rustcorp.com.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.