Added "Ben Hutchings <ben@xxxxxxxxxxxxxxx>"
On Wed, Jan 5, 2022 at 3:13 AM Matthew Wilcox <willy@xxxxxxxxxxxxx> 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
