linux-kernel - Re: [PATCH v2] builddeb: Support signing kernels with the module signing key

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 7 Feb 2022 21:33:46 +0900
From:   Masahiro Yamada <masahiroy@...nel.org>
To:     Matthew Wilcox <willy@...radead.org>,
        Ben Hutchings <ben@...adent.org.uk>
Cc:     Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        efi@...ts.einval.com,
        debian-kernel <debian-kernel@...ts.debian.org>,
        linux-efi <linux-efi@...r.kernel.org>,
        Ard Biesheuvel <ardb@...nel.org>,
        David Woodhouse <dwmw2@...radead.org>,
        David Howells <dhowells@...hat.com>, keyrings@...r.kernel.org
Subject: Re: [PATCH v2] builddeb: Support signing kernels with the module
 signing key

Added "Ben Hutchings <ben@...adent.org.uk>"

On Wed, Jan 5, 2022 at 3:13 AM Matthew Wilcox <willy@...radead.org> wrote:
>
> On Wed, Jan 05, 2022 at 12:39:57AM +0900, Masahiro Yamada wrote:
> > > +vmlinux=$($MAKE -s -f $srctree/Makefile image_name)
> > > +key=
> > > +if is_enabled CONFIG_EFI_STUB && is_enabled CONFIG_MODULE_SIG; then
> > > +       cert=$(grep ^CONFIG_MODULE_SIG_KEY= include/config/auto.conf | cut -d\" -f2)
> > > +       if [ ! -f $cert ]; then
> > > +               cert=$srctree/$cert
> > > +       fi
> > > +
> > > +       key=${cert%pem}priv
> > > +       if [ ! -f $key ]; then
> > > +               key=$cert
> > > +       fi
> >
> >
> > I still do not understand this part.
> >
> > It is true that the Debian document you referred to creates separate files
> > for the key and the certificate:
> >   # openssl req -new -x509 -newkey rsa:2048 -keyout MOK.priv -outform
> > DER -out MOK.der -days 36500 -subj "/CN=My Name/" -nodes
> >
> > but, is such a use-case possible in Kbuild?
>
> If someone has followed the Debian instructions for creating a MOK,
> then they will have two separate files.  We should support both the case
> where someone has created a Debian MOK and the case where someone has
> used Kbuild to create this foolish blob with both private and public
> key in one file.

But, this patch is doing different things than the Debian document.


The Debian document you referred to says:
  "Ubuntu puts its MOK key under /var/lib/shim-signed/mok/ and some
   software such as Oracle's virtualbox package expect the key there
   so we follow suit (see 989463 for reference) and put it at the same place"



In Debian, MOK is generated under /var/lib/shim-signed/mok/,
and its primary use is for signing the kernel.
Then, you can reuse it for signing modules as well.


This patch adopts the opposite direction:
  Kbuild generates the module signing key, then
  this patch reuses it for singing the kernel.

The key is located in the kernel build tree
(that is, the key is lost when you run "make mrproper").

You need to "mokutil --import path/to/module/sining/key"
every time Kbuild generates a new key.



So, another possible approach is:

builddeb signs the kernel with the key
in /var/lib/shim-signed/mok/.

I think this is more aligned with the debian documenation.

I added Ben Hutchings, who might give us insights.







> > In the old days, yes, the key and the certificate were stored in separate files.
> > (the key in *.priv and the certificate in *.x509)
> >
> >
> > Please read this commit:
>
> Yes, I did.
>
> > The motivation for this change is still questionable to me;
> > the commit description sounds like they merged *.priv and *.x509
> > into *.pem just because they could not write a correct Makefile.
> > (If requested, I can write a correct Makefile that works in parallel build)
>
> I think that would be preferable.  Putting the private and public keys
> in the same file cannot be good security practice!



-- 
Best Regards
Masahiro Yamada