Regarding Signing Linux kernel with Microsoft secure boot keys for UEFI

[inventsekar]

Hi All.... Thx for your answers ... Great learning... I will reread them
and understand better slowly and thoroughly.

On Sun 8 Jul, 2018, 11:20 PM , <valdis.kletnieks at vt.edu> wrote:

> On Sun, 08 Jul 2018 11:21:08 +0530, inventsekar said:
>
> > I read this page few times but I am unable to understand what's Linus's
> > idea..Why he disagree ...
> > whether the Linux kernel should include code that makes it easier to boot
> > Linux on Windows PCs.
>
> The issue is "trusted boot", and it doesn't actually make it easier to
> boot Linux.
>
> The problem is that the obvious way to implement it for a distro requires
> an
> intermediate key signed by Microsoft.
>
> In other words, you can't do it easily without Microsoft's permission.
> Although
> pretty much all UEFI boxes that support secure boot allow installing
> trusted
> private keys, it's not something you can do in the middle of an Ubuntu
> install -
> it requires dropping down into the BIOS screens and setting a bunch of
> stuff.
>
> So the only way to do it in a distro-friendly manner without involving
> Microsoft is to have the Linux Foundation or similar non-distro entity
> create a
> public/private key pair, and somebody gets *all* the vendors to include
> that
> key as well as Mirosoft's key.  Dell, Lenovo, Toshiba, And all the others.
> Because any vendor that doesn't include it will get reports on the web
> "Trusted
> boot of Linux on Zen-Cheap doesn't work."
>
> Which, of course, most hardware manufacturers don't give a rat's tail
> about,
> because if they did, they'd fix their buggy BIOS that create pages on the
> web
> "suspend doesn't work on Zen-Cheap".
>
> (In actual practice, what happened was that somebody got Microsoft to sign
> an intermediate UEFI blob that allows bootstrapping a Linux kernel, and
> distros
> have included that blob.  However, just like linux-firmware is packaged
> separately
> from the kernel due to the differing license on most firmware (which isn't
> GPL),
> that blob has to be distributed separate from the kernel as well.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20180710/6fbe8890/attachment.html>