Bug#922251: live-build: support syslinux-efi as (additional) bootloader

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Bug#922251: live-build: support syslinux-efi as (additional) bootloader

Matthijs Kooijman-3
Package: live-build
Version: 1:20180925
Severity: wishlist

Hi folks,

currently, live-build seems to only support EFI systems using the
grub-efi bootloader, but not for netboot or hdd images (effectively only
for iso images, I believe).

Syslinux also has an EFI version, that can be installed through
the syslinux-efi package. It would be useful for live-build to support
this. I need this for a client, so I'm planning to implement support in
the coming weeks. This report serves to track progress and discuss
the implementation.

I've done some experiments by adding syslinux-efi to an existing image
manually (not with a full live-build image, but with my own hdd image
that at least uses live-build for building the image, so should be
representative in this area). This shows that adding syslinux-efi is
fairly easy. The existing FAT partition can function as an ESP (EFI
System Partition) as it is now.

Installing the bootloader is a matter of dumping some files in the
EFI/BOOT directory. This lets the bootloader be detected as a fallback
bootloader, which is AFAIU intended for removable media. Syslinux needs
some additional files (ldlinux, additional modules, configuration) which
can live in that same directory.

Both 32-bit and 64-bit EFI can be supported at the same time, by
installing both versions of syslinux-efi (named bootx64.efi and
bootia32.efi respectively). One caveat is that syslinux needs different
.c32 modules for both architectures (though they are both named .c32 and
are explicitly referenced in the config file). This means either
duplicating the bootloader configuration file for 32 and 64 bit (which
hinders modifications to the config), or putting the modules in
subdirectories and using the PATH config directive to point to either
directive before including the common configuration. I have not tried
this latter approach but it is described here (though currently
syslinux.org seems to be unavailable, I tried the Google cache):

https://www.syslinux.org/archives/2014-August/022545.html

(subject: syslinux efi configuration file name proposal)

I've also tried to let the syslinux-efi config file include the normal
syslinux configuration file (or at least the bulk that is in live.cfg),
which seems to work just fine.

Since config sharing is easy and syslinux-efi is a matter of adding some
files to the existing image, it would make sense to add syslinux-efi by
default on normal syslinux hdd images (perhaps adding a new option to
disable this?). This also seems to hold for ISO9660 images, where
it seems isohybrid can include a small FAT filesystem with the
bootloader files. This might need some additional work to generate the
filesystem image and/or pass options when generating the iso. See:

https://www.syslinux.org/wiki/index.php?title=Isohybrid#UEFI


Using syslinux-efi exclusively (e.g. passing it to --bootloader and not
installing normal syslinux) might also be an extra option. However, I'm
not much interested in this case, so I will likely not implement it
(I'll try not to make it too hard to add it later).


In terms of code, this is probably best implemented in the existing
binary_syslinux script. The bulk of what needs to happen is essentially
copying bootloader files from config/bootloaders into binary, taking
care to resolve symlinks. I'm planning to put the code that does that
into a shell function, so it can be called at the current place and then
a second time for syslinux-efi later.

I think it would be good to copy files *from*
config/bootloaders/syslinux-efi-addon or something similar, to leave
config/bootloaders/syslinux-efi available for an EFI-only image. These
two directories would be identical in terms of syslinux binary files,
but the configurations would differ (the addon would include the normal
boot/syslinux/syslinux.cfg, while the standalone version would contain
the complete config).

I haven't really looked at the iso version yet (which is also not my
primary interest, but I think it would be good to handle as well).

Happy to hear any thoughts :-)

Gr.

Matthijs

Reply | Threaded
Open this post in threaded view
|

Bug#922251: live-build: support syslinux-efi as (additional) bootloader

Luca Boccassi-3
On Wed, 2019-02-13 at 20:57 +0100, Matthijs Kooijman wrote:

> Package: live-build
> Version: 1:20180925
> Severity: wishlist
>
> Hi folks,
>
> currently, live-build seems to only support EFI systems using the
> grub-efi bootloader, but not for netboot or hdd images (effectively
> only
> for iso images, I believe).
>
> Syslinux also has an EFI version, that can be installed through
> the syslinux-efi package. It would be useful for live-build to
> support
> this. I need this for a client, so I'm planning to implement support
> in
> the coming weeks. This report serves to track progress and discuss
> the implementation.
>
> I've done some experiments by adding syslinux-efi to an existing
> image
> manually (not with a full live-build image, but with my own hdd image
> that at least uses live-build for building the image, so should be
> representative in this area). This shows that adding syslinux-efi is
> fairly easy. The existing FAT partition can function as an ESP (EFI
> System Partition) as it is now.
>
> Installing the bootloader is a matter of dumping some files in the
> EFI/BOOT directory. This lets the bootloader be detected as a
> fallback
> bootloader, which is AFAIU intended for removable media. Syslinux
> needs
> some additional files (ldlinux, additional modules, configuration)
> which
> can live in that same directory.
>
> Both 32-bit and 64-bit EFI can be supported at the same time, by
> installing both versions of syslinux-efi (named bootx64.efi and
> bootia32.efi respectively). One caveat is that syslinux needs
> different
> .c32 modules for both architectures (though they are both named .c32
> and
> are explicitly referenced in the config file). This means either
> duplicating the bootloader configuration file for 32 and 64 bit
> (which
> hinders modifications to the config), or putting the modules in
> subdirectories and using the PATH config directive to point to either
> directive before including the common configuration. I have not tried
> this latter approach but it is described here (though currently
> syslinux.org seems to be unavailable, I tried the Google cache):
>
> https://www.syslinux.org/archives/2014-August/022545.html
>
> (subject: syslinux efi configuration file name proposal)
>
> I've also tried to let the syslinux-efi config file include the
> normal
> syslinux configuration file (or at least the bulk that is in
> live.cfg),
> which seems to work just fine.
>
> Since config sharing is easy and syslinux-efi is a matter of adding
> some
> files to the existing image, it would make sense to add syslinux-efi
> by
> default on normal syslinux hdd images (perhaps adding a new option to
> disable this?). This also seems to hold for ISO9660 images, where
> it seems isohybrid can include a small FAT filesystem with the
> bootloader files. This might need some additional work to generate
> the
> filesystem image and/or pass options when generating the iso. See:
>
> https://www.syslinux.org/wiki/index.php?title=Isohybrid#UEFI
>
>
> Using syslinux-efi exclusively (e.g. passing it to --bootloader and
> not
> installing normal syslinux) might also be an extra option. However,
> I'm
> not much interested in this case, so I will likely not implement it
> (I'll try not to make it too hard to add it later).
>
>
> In terms of code, this is probably best implemented in the existing
> binary_syslinux script. The bulk of what needs to happen is
> essentially
> copying bootloader files from config/bootloaders into binary, taking
> care to resolve symlinks. I'm planning to put the code that does that
> into a shell function, so it can be called at the current place and
> then
> a second time for syslinux-efi later.
>
> I think it would be good to copy files *from*
> config/bootloaders/syslinux-efi-addon or something similar, to leave
> config/bootloaders/syslinux-efi available for an EFI-only image.
> These
> two directories would be identical in terms of syslinux binary files,
> but the configurations would differ (the addon would include the
> normal
> boot/syslinux/syslinux.cfg, while the standalone version would
> contain
> the complete config).
>
> I haven't really looked at the iso version yet (which is also not my
> primary interest, but I think it would be good to handle as well).
>
> Happy to hear any thoughts :-)
>
> Gr.
>
> Matthijs
Hi,

At a quick glance it all sounds good to me, although I can't say I have
a lot of experience with syslinux.

For feature parity, I'd encourage to look into supporting Secure Boot
like the grub-efi implementation does, since we are preparing to ship
that in Debian 10. It's not much extra work on top of adding the rest
anyway.

--
Kind regards,
Luca Boccassi

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#922251: live-build: support syslinux-efi as (additional) bootloader

Thomas Schmitt
In reply to this post by Matthijs Kooijman-3
Hi,

Matthijs Kooijman wrote:
> it seems isohybrid can include a small FAT filesystem with the
> bootloader files. [...]
> https://www.syslinux.org/wiki/index.php?title=Isohybrid#UEFI

This describes the equipment of debian-live and debian-cd (DVD-*, BD-*,
netinst) ISOs. See e.g. debian-live-9.5.0-i386-xfce.iso and its
MBR partition table.

Debian and nearly all others use GRUB 2 for their EFI capable ISOs.
See Knoppix 8.[12] for examples of SYSLINUX EFI in ISOs.

SYSLINUX EFI stuff is known not to boot from CD, DVD, or BD, but only from
HDD, SSD, and alike.


Have a nice day :)

Thomas

Reply | Threaded
Open this post in threaded view
|

Bug#922251: live-build: support syslinux-efi as (additional) bootloader

Matthijs Kooijman-3
Hi Thomas,

> > it seems isohybrid can include a small FAT filesystem with the
> > bootloader files. [...]
> > https://www.syslinux.org/wiki/index.php?title=Isohybrid#UEFI
>
> This describes the equipment of debian-live and debian-cd (DVD-*, BD-*,
> netinst) ISOs. See e.g. debian-live-9.5.0-i386-xfce.iso and its
> MBR partition table.
I'm a bit confused by your message. When you say "This", are you
referring to the syslinux isohybrid page?

> Debian and nearly all others use GRUB 2 for their EFI capable ISOs.
> See Knoppix 8.[12] for examples of SYSLINUX EFI in ISOs.
>
> SYSLINUX EFI stuff is known not to boot from CD, DVD, or BD, but only from
> HDD, SSD, and alike.
Again, I'm confused. If syslinux-efi is known not to boot from
CD/DVD/BD, then why do they document how to include it into an isohybrid
image? Or does it then only work when booting the isohybrid image from a
HDD, rather than CD?

Gr.

Matthijs

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#922251: live-build: support syslinux-efi as (additional) bootloader

Matthijs Kooijman-3
In reply to this post by Luca Boccassi-3
Hey Luca,

> At a quick glance it all sounds good to me, although I can't say I have
> a lot of experience with syslinux.
Ok.

> For feature parity, I'd encourage to look into supporting Secure Boot
> like the grub-efi implementation does, since we are preparing to ship
> that in Debian 10. It's not much extra work on top of adding the rest
> anyway.
Can you elaborate a bit on how grub-efi supports Secure Boot exactly? I
can't really find anything about this in the code?

Looking at build/scripts/binary_grub-efi and build/scripts/efi-image, I
see that a new efi firmware binary is built using grub-mkimage, so I
suppose that that image is not already signed, and there is nothing
suggesting that image is be signed at that time. Looking at binary_iso
there is also no reference to signing or secure boot.

AFAIU, to support secure boot, you need to sign the bootloader,
typically using a key from MS. I've read about the Shim bootloader,
which is signed and typically used to then load grub or other
bootloaders (signed by the Debian key or other keys included in Shim).
However, I can see no reference to shim either.

Looking at the grub package more closely, I *think* that it installs shim
alongside grub when using grub-install, but that is not used here?

Regardless, how would you suggest we "support Secure Boot" with
syslinux-efi exactly? AFAICT there is no syslinux-efi image available
signed with the MS key, and I suspect it is not signed with the Debian
key or any other key used by shim (also, since syslinux does not seem to
support key verification on kernels, I guess there is no secure way to
get syslinux booting under secure boot without compromising secure boot,
but I might be missing an important point about SB here...).

> > Since config sharing is easy and syslinux-efi is a matter of adding
> > some files to the existing image, it would make sense to add
> > syslinux-efi by default on normal syslinux hdd images (perhaps
> > adding a new option to disable this?).

I just noticed that lb config has a --bootloaders that supports
*multiple* bootloaders, so that would be perfect way to support this.
E.g. --bootloaders syslinux,syslinux-efi to have combined image (which
would also become the default for hdd images), or an explicit
--bootloaders syslinux or --bootloaders syslinux-efi to choose either
one individually.

Gr.

Matthijs

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#922251: live-build: support syslinux-efi as (additional) bootloader

Thomas Schmitt
In reply to this post by Matthijs Kooijman-3
Hi,

Matthijs Kooijman wrote:
> > > https://www.syslinux.org/wiki/index.php?title=Isohybrid#UEFI

I wrote:
> > This describes the equipment of debian-live and debian-cd [...]

> I'm a bit confused by your message. When you say "This", are you
> referring to the syslinux isohybrid page?

Yes. The doings of SYSLINUX program "isohybrid" are also implemented in
libisofs underneath xorriso.

It was me who wrote that wiki page with info collected from the
mailing list [hidden email] and with my knowledge as developer of
libisofs and xorriso.
But currently i get "Connection refused" when trying to connect to
www.syslinux.org. So i can only see the Google "cached" document or
a text draft of mine from june 2014.


> > SYSLINUX EFI stuff is known not to boot from CD, DVD, or BD, but only from
> > HDD, SSD, and alike.

> Again, I'm confused. If syslinux-efi is known not to boot from
> CD/DVD/BD, then why do they document how to include it into an isohybrid
> image?

A little discussion on the list resulted in the decision not to mention
the SYSLINUX EFI problems or GRUB2. Courtesy among upstreams ...

Regrettably there is still no official position towards the failure with
SYSLINUX EFI code booting via El Torito from optical media.
But already the inventor of the "isohybrid" program's --uefi option,
Matthew J. Garrett equipped his Fedora ISOs by EFI software from GRUB2
together with BIOS software from SYSLINUX. (Plus some HFS+ filesystem
image pointed to by an Apple Partition Map.)
Maybe Steve McIntyre can contribute an anecdote how he came to the
decision in debian-cd to use GRUB2 for EFI and thus to create the need
for two independent boot menu configurations.

Klaus Knopper, on the other hand, believes that it could work on some
machines. But he tested only with virtual machines and i found no
confirmation that it works on any real iron in native EFI mode from DVD.
See e.g. this 4 GB image:
  http://ftp.uni-kl.de/pub/linux/knoppix-dvd/KNOPPIX_V8.2-2018-05-10-EN.iso


> Or does it then only work when booting the isohybrid image from a
> HDD, rather than CD?

If you find a real machine that boots in native EFI mode Knoppix 8 from DVD,
then this would be a novelty.  (Virtual machine firmware is known to be
sloppy with the distinction of HDD and CD-ROM boot paths.)
 

Have a nice day :)

Thomas

Reply | Threaded
Open this post in threaded view
|

Bug#922251: live-build: support syslinux-efi as (additional) bootloader

Andreas Heinlein-2
Am 14.02.2019 um 17:35 schrieb Thomas Schmitt:
> Maybe Steve McIntyre can contribute an anecdote how he came to the
> decision in debian-cd to use GRUB2 for EFI and thus to create the need
> for two independent boot menu configurations.

I am only taking a guess here, but maybe he just took over something
that was already done in Ubuntu. IIRC, Ubuntu 12.04 was the first distro
to support EFI booting (without Secure Boot, that was introduced in
14.04 via shim), and they did it that way. One reason was that Syslinux
EFI wasn't ready at that time. The other one was that Ubuntu
traditionally put a lot of effort into user experience, and they were
using gfxboot as menu system with legacy syslinux. Unfortunately,
gfxboot hadn't been ported to EFI the last time I asked about two years
ago. A quick google search didn't turn up anything new, so I guess that
is still the case. Someone on the syslinux mailing list told me that the
gfxboot code was actually from someone not directly involved with
syslinux and more or less abandoned, so someone would have to dive into
it and port it to EFI. That means if you want to use syslinux EFI, you
will have to stick with its traditional menu system. On the other hand,
grub themes allowed for similar "shiny" menus so they chose this.

Bye,

Andreas

Reply | Threaded
Open this post in threaded view
|

Bug#922251: live-build: support syslinux-efi as (additional) bootloader

Luca Boccassi-3
In reply to this post by Matthijs Kooijman-3
On Thu, 2019-02-14 at 17:18 +0100, Matthijs Kooijman wrote:

> Hey Luca,
>
> > At a quick glance it all sounds good to me, although I can't say I
> > have
> > a lot of experience with syslinux.
>
> Ok.
>
> > For feature parity, I'd encourage to look into supporting Secure
> > Boot
> > like the grub-efi implementation does, since we are preparing to
> > ship
> > that in Debian 10. It's not much extra work on top of adding the
> > rest
> > anyway.
>
> Can you elaborate a bit on how grub-efi supports Secure Boot exactly?
> I
> can't really find anything about this in the code?
>
> Looking at build/scripts/binary_grub-efi and build/scripts/efi-image,
> I
> see that a new efi firmware binary is built using grub-mkimage, so I
> suppose that that image is not already signed, and there is nothing
> suggesting that image is be signed at that time. Looking at
> binary_iso
> there is also no reference to signing or secure boot.
>
> AFAIU, to support secure boot, you need to sign the bootloader,
> typically using a key from MS. I've read about the Shim bootloader,
> which is signed and typically used to then load grub or other
> bootloaders (signed by the Debian key or other keys included in
> Shim).
> However, I can see no reference to shim either.
>
> Looking at the grub package more closely, I *think* that it installs
> shim
> alongside grub when using grub-install, but that is not used here?
>
> Regardless, how would you suggest we "support Secure Boot" with
> syslinux-efi exactly? AFAICT there is no syslinux-efi image available
> signed with the MS key, and I suspect it is not signed with the
> Debian
> key or any other key used by shim (also, since syslinux does not seem
> to
> support key verification on kernels, I guess there is no secure way
> to
> get syslinux booting under secure boot without compromising secure
> boot,
> but I might be missing an important point about SB here...).
So for the secure boot case in binary_grub-efi, what we do is that if
the signed monolithic EFI binaries are available we copy those instead
of building a new image. As you correctly mentioned these have to be
signed already, so we can't do that when building the image, but they
are already available in the Debian archive as packages.

Here we check if they are available:

https://salsa.debian.org/live-team/live-build/blob/master/scripts/build/binary_grub-efi#L79

Here we copy the binaries in the right places:

https://salsa.debian.org/live-team/live-build/blob/master/scripts/build/binary_grub-efi#L164

> > > Since config sharing is easy and syslinux-efi is a matter of
> > > adding
> > > some files to the existing image, it would make sense to add
> > > syslinux-efi by default on normal syslinux hdd images (perhaps
> > > adding a new option to disable this?).
>
> I just noticed that lb config has a --bootloaders that supports
> *multiple* bootloaders, so that would be perfect way to support this.
> E.g. --bootloaders syslinux,syslinux-efi to have combined image
> (which
> would also become the default for hdd images), or an explicit
> --bootloaders syslinux or --bootloaders syslinux-efi to choose either
> one individually.
>
> Gr.
>
> Matthijs
Yes we do support that - although not all combinations work IIRC.

--
Kind regards,
Luca Boccassi

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#922251: live-build: support syslinux-efi as (additional) bootloader

Steve McIntyre
In reply to this post by Thomas Schmitt
Hey folks,

On Thu, Feb 14, 2019 at 05:35:48PM +0100, Thomas Schmitt wrote:

...

>Regrettably there is still no official position towards the failure with
>SYSLINUX EFI code booting via El Torito from optical media.
>But already the inventor of the "isohybrid" program's --uefi option,
>Matthew J. Garrett equipped his Fedora ISOs by EFI software from GRUB2
>together with BIOS software from SYSLINUX. (Plus some HFS+ filesystem
>image pointed to by an Apple Partition Map.)
>Maybe Steve McIntyre can contribute an anecdote how he came to the
>decision in debian-cd to use GRUB2 for EFI and thus to create the need
>for two independent boot menu configurations.
>
>Klaus Knopper, on the other hand, believes that it could work on some
>machines. But he tested only with virtual machines and i found no
>confirmation that it works on any real iron in native EFI mode from DVD.
>See e.g. this 4 GB image:
>  http://ftp.uni-kl.de/pub/linux/knoppix-dvd/KNOPPIX_V8.2-2018-05-10-EN.iso

Ady on the syslinux list has repeatedly argued against people
suggesting that syslinux-efi will work for disk/CD hybrid media. I've
not looked at the code to see why - I have no desire to, :-)

--
Steve McIntyre, Cambridge, UK.                                [hidden email]
The two hard things in computing:
 * naming things
 * cache invalidation
 * off-by-one errors                  -- Stig Sandbeck Mathisen

Reply | Threaded
Open this post in threaded view
|

Bug#922251: live-build: support syslinux-efi as (additional) bootloader

Steve McIntyre
In reply to this post by Thomas Schmitt
[ Gah, missed this bit... ]

On Thu, Feb 14, 2019 at 05:35:48PM +0100, Thomas Schmitt wrote:

...

>Maybe Steve McIntyre can contribute an anecdote how he came to the
>decision in debian-cd to use GRUB2 for EFI and thus to create the need
>for two independent boot menu configurations.

We already had working isohybrid media and I didn't want to drop that
- in my opinion it's a very important feature. Plus, when I first
started hacking on EFI things back in 2011 (or was it 2012? not sure)
I genuinely could not get syslinux to do anything useful with EFI. As
I already knew that people had EFI working with GRUB for booting off
disk, I went that way and had a prototype running in a couple of
days. Hacking on menus etc. was relatvely easy in comparison after
that.

Once we had that, it was an obvious step to use the same setup on live
media as was already known to work on installation media.

In fact, one of the projects I've been trying to get to for a couple
of years now is simplifying things by going the other way: using GRUB
for everything and dropping syslinux on Debian media.

I guess I can see the attraction of syslinux, but I don't want to use
it any more if I can avoid it. GRUB is massively more flexible and
powerful. It's cross-platform (x86, arm32/arm64, sparc, powerpc, mips
at least), actively maintained and reasonably well understood by quite
a large group of people. It's far from perfect (as we all know!), but
I think it's the best solution we have.

That's my story for Debian EFI...

--
Steve McIntyre, Cambridge, UK.                                [hidden email]
"I can't ever sleep on planes ... call it irrational if you like, but I'm
 afraid I'll miss my stop" -- Vivek Das Mohapatra

Reply | Threaded
Open this post in threaded view
|

Bug#922251: live-build: support syslinux-efi as (additional) bootloader

Steve McIntyre
In reply to this post by Matthijs Kooijman-3
Hi Matthijs,

There's quite a lot of text here - I hope it helps! :-)

On Thu, Feb 14, 2019 at 05:18:42PM +0100, Matthijs Kooijman wrote:

>
>> For feature parity, I'd encourage to look into supporting Secure Boot
>> like the grub-efi implementation does, since we are preparing to ship
>> that in Debian 10. It's not much extra work on top of adding the rest
>> anyway.
>Can you elaborate a bit on how grub-efi supports Secure Boot exactly? I
>can't really find anything about this in the code?
>
>Looking at build/scripts/binary_grub-efi and build/scripts/efi-image, I
>see that a new efi firmware binary is built using grub-mkimage, so I
>suppose that that image is not already signed, and there is nothing
>suggesting that image is be signed at that time. Looking at binary_iso
>there is also no reference to signing or secure boot.
>
>AFAIU, to support secure boot, you need to sign the bootloader,
>typically using a key from MS. I've read about the Shim bootloader,
>which is signed and typically used to then load grub or other
>bootloaders (signed by the Debian key or other keys included in Shim).
>However, I can see no reference to shim either.
>
>Looking at the grub package more closely, I *think* that it installs shim
>alongside grub when using grub-install, but that is not used here?

MS won't sign GRUB directly due to the licensing. So that's one of the
reasons why shim was developed. It's a small piece of software which
lives entirely in the UEFI environment and can be readily
verified. The shim binary shipped by each distro includes a public key
*specific to that distro* which is used to verify the rest of the
stack that comes afterwards (GRUB -> Linux, normally). Machine Owner
Keys (MOK) can be added too, under the control of the Machine Owner
(hence the name!) rather than by the distro. GRUB has some knowledge
of how SB works, but AFAIK there's not much needed - it's calling into
APIs provided by the UEFI platform and shim underneath it.

Debian has a shim binary signed by Microsoft, including our own
key. We have implemented a process to create signed versions of a very
small number of our own packages:

 * GRUB
 * Linux
 * fwupd
 * fwupdate

and you can find those signed versions in the archive in Sid and
Buster.

In terms of building a grub binary is well-understood, as you can see
in the build/scripts/efi-image script in live-build. But that will
never give you a signed binary. Instead, if you look in the equivalent
efi-image script in the d-i build system you'll see that it's been
updated. For some arches (amd64 only so far, with others to come), we
still build the grubXXXX.efi binary, but where possible we grab the
binary directly from the -signed package in the archive so we can keep
that signature.

For Debian's official live images built with live-wrapper, we just
pull in the same files that d-i has created so we inherit the same SB
support.

>Regardless, how would you suggest we "support Secure Boot" with
>syslinux-efi exactly? AFAICT there is no syslinux-efi image available
>signed with the MS key, and I suspect it is not signed with the Debian
>key or any other key used by shim (also, since syslinux does not seem to
>support key verification on kernels, I guess there is no secure way to
>get syslinux booting under secure boot without compromising secure boot,
>but I might be missing an important point about SB here...).

No, you're correct. syslinux is not in a state to do SB at all, and I
can't see it happening any time soon.

--
Steve McIntyre, Cambridge, UK.                                [hidden email]
Dance like no one's watching. Encrypt like everyone is.
 - @torproject

Reply | Threaded
Open this post in threaded view
|

Bug#922251: live-build: support syslinux-efi as (additional) bootloader

Luca Boccassi-3
In reply to this post by Luca Boccassi-3
On Thu, 2019-02-14 at 18:35 +0000, Luca Boccassi wrote:

> On Thu, 2019-02-14 at 17:18 +0100, Matthijs Kooijman wrote:
> > Hey Luca,
> >
> > > At a quick glance it all sounds good to me, although I can't say
> > > I
> > > have
> > > a lot of experience with syslinux.
> >
> > Ok.
> >
> > > For feature parity, I'd encourage to look into supporting Secure
> > > Boot
> > > like the grub-efi implementation does, since we are preparing to
> > > ship
> > > that in Debian 10. It's not much extra work on top of adding the
> > > rest
> > > anyway.
> >
> > Can you elaborate a bit on how grub-efi supports Secure Boot
> > exactly?
> > I
> > can't really find anything about this in the code?
> >
> > Looking at build/scripts/binary_grub-efi and build/scripts/efi-
> > image, 
> > I
> > see that a new efi firmware binary is built using grub-mkimage, so
> > I
> > suppose that that image is not already signed, and there is nothing
> > suggesting that image is be signed at that time. Looking at
> > binary_iso
> > there is also no reference to signing or secure boot.
> >
> > AFAIU, to support secure boot, you need to sign the bootloader,
> > typically using a key from MS. I've read about the Shim bootloader,
> > which is signed and typically used to then load grub or other
> > bootloaders (signed by the Debian key or other keys included in
> > Shim).
> > However, I can see no reference to shim either.
> >
> > Looking at the grub package more closely, I *think* that it
> > installs
> > shim
> > alongside grub when using grub-install, but that is not used here?
> >
> > Regardless, how would you suggest we "support Secure Boot" with
> > syslinux-efi exactly? AFAICT there is no syslinux-efi image
> > available
> > signed with the MS key, and I suspect it is not signed with the
> > Debian
> > key or any other key used by shim (also, since syslinux does not
> > seem
> > to
> > support key verification on kernels, I guess there is no secure way
> > to
> > get syslinux booting under secure boot without compromising secure
> > boot,
> > but I might be missing an important point about SB here...).
>
> So for the secure boot case in binary_grub-efi, what we do is that if
> the signed monolithic EFI binaries are available we copy those
> instead
> of building a new image. As you correctly mentioned these have to be
> signed already, so we can't do that when building the image, but they
> are already available in the Debian archive as packages.
>
> Here we check if they are available:
>
> https://salsa.debian.org/live-team/live-build/blob/master/scripts/bui
> ld/binary_grub-efi#L79
>
> Here we copy the binaries in the right places:
>
> https://salsa.debian.org/live-team/live-build/blob/master/scripts/bui
> ld/binary_grub-efi#L164
Ah silly me, I forgot something simple but quite fundamental: the point
of syslinux is to avoid using grub entirely.

Then disregard anything I've said. D'oh!

--
Kind regards,
Luca Boccassi

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#922251: live-build: support syslinux-efi as (additional) bootloader

Thomas Schmitt
In reply to this post by Steve McIntyre
Hi,

Steve McIntyre wrote:
> Ady on the syslinux list has repeatedly argued against people
> suggesting that syslinux-efi will work for disk/CD hybrid media.

Ady emphasized that it does work with HDD. It was others and me who
pointed out that nobody ever could show success with CD-ROM on real iron.

For a short while Klaus Knopper convinced me that his complete mini-GNU/Linux
inside the EFI partition could solve the problem. But then appeared
negative reports on the german support forum and no positive ones.
It does work from USB stick but still not from DVD.


I wrote:
> > > Maybe Steve McIntyre can contribute an anecdote how he came to the
> > > decision in debian-cd to use GRUB2 for EFI

Andreas Heinlein wrote:
> > I am only taking a guess here, but maybe he just took over something
> > that was already done in Ubuntu. IIRC, Ubuntu 12.04 was the first distro
> > to support EFI booting

ubuntu-12.04-server-amd64.iso indeed has an EFI boot image in its El Torito
catalog. The MBR partition table does not have an entry of type 0xef, though.
So it was not treated by isohybrid option --uefi.

The boot image has the path "/boot/grub/efi.img", a FAT filesystem with
only one data file
  /EFI/BOOT/BOOTX64.EFI
of which the end looks much like Debian's BOOTX64.EFI when it tries to hop
from EFI partition to ISO filesystem:
  search --file --set=root /.disk/info
  set prefix=($root)/boot/grub/x86_64-efi
  source $prefix/grub.cfg

In debian-9.3.0-amd64-netinst.iso we can see:
  search --file --set=root /.disk/info
  set prefix=($root)/boot/grub
  source $prefix/x86_64-efi/grub.cfg
  (memdisk)/boot/grub

So possibly Colin Watson was the one who first used this GRUB gesture
within the EFI partition / boot image.


Steve McIntyre wrote:
> We already had working isohybrid media and I didn't want to drop that
> - in my opinion it's a very important feature.
> [...]
> In fact, one of the projects I've been trying to get to for a couple
> of years now is simplifying things by going the other way: using GRUB
> for everything and dropping syslinux on Debian media.

See results of program grub-mkrescue when grub-pc and grub-efi-ia32-bin or
grub-efi-amd64-bin are installed.

The main disadvantage of grub-mkrescue ISOs with EFI partition is the
lack of a mountable ISO partition. For exploring other layouts, i made a
man-in-the-middle script to be run as

   grub-mkrescue --xorriso=frontend/grub-mkrescue-sed.sh ...

which manipulates the xorrisofs options before running the real xorriso.

I like the result of its default mode "mbr_only" and of mode "gpt_appended"
both with -partition_offset 16.
See
  https://dev.lovelyhq.com/libburnia/libisoburn/raw/master/frontend/grub-mkrescue-sed.sh


Have a nice day :)

Thomas

Reply | Threaded
Open this post in threaded view
|

Bug#922251: live-build: support syslinux-efi as (additional) bootloader

Matthijs Kooijman-3
In reply to this post by Luca Boccassi-3
Hey Luca,

> > So for the secure boot case in binary_grub-efi, what we do is that
> > if the signed monolithic EFI binaries are available we copy those
> > instead of building a new image.
> >
> > ...
> >
> > https://salsa.debian.org/live-team/live-build/blob/master/scripts/build/binary_grub-efi#L79
Aha! Turns out I was looking at an old version, I messed up my git
checkout apparently. That script indeed does what I would expect:
Install shim alongside grub and use signed grub to make shim load it.

> Ah silly me, I forgot something simple but quite fundamental: the point
> of syslinux is to avoid using grub entirely.

But indeed, I was aiming for syslinux, so none of this secure boot stuff
will actually work with syslinux.

Gr.

Matthijs

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#922251: live-build: support syslinux-efi as (additional) bootloader

Matthijs Kooijman-3
In reply to this post by Steve McIntyre
Hi Steve,

> In fact, one of the projects I've been trying to get to for a couple
> of years now is simplifying things by going the other way: using GRUB
> for everything and dropping syslinux on Debian media.

Hm, that's another interesting thought. I was aiming for syslinux, since
our current setup uses that (along with some custom configuration).
However, that seems to be impossible to work with secure boot (which
would be nice to have) and impossible to boot from optical media (which
for my personal case is not an issue).

I could imagine switching to grub completely (which means that this
issue changes from "add syslinux-efi" to "make grub-pc & grub-efi work
for hdd images"), though that's probably a bit more work for me and my
client.  I'll dig in a bit deeper to see how much work that would be.

Thanks for everyone's input so far!

Gr.

Matthijs

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#922251: live-build: support syslinux-efi as (additional) bootloader

Matthijs Kooijman-3
In reply to this post by Luca Boccassi-3
Hi Luca & others,

I've been working on syslinux-efi support in the past weeks and just
submitted a MR with a working implementation, along with some small
bootloader-related cleanups and refactors:

        https://salsa.debian.org/live-team/live-build/merge_requests/19

In the end, I opted to implement syslinux-efi rather than make grub-efi
work on hdd images, since that seemed easier and allows preserving the
existing bootloader config files in our project. Getting grub-efi to
work on hdd images might still be an interesting project that could be
implemented alongside syslinux-efi support, though I do not have any
specific purpose for it as of yet.

As predicted by others in this bug report, my work does not enable
secure boot (which syslinux simply does not support), nor enable
syslinux-efi support in iso/isohybrid images (since syslinux-efi does
not support this, or at least it apparently does not work).

Gr.

Matthijs

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#922251: live-build: support syslinux-efi as (additional) bootloader

adrian15
El 08/04/19 a las 21:29, Matthijs Kooijman escribió:
> Hi Luca & others,
>
> I've been working on syslinux-efi support in the past weeks and just
> submitted a MR with a working implementation, along with some small
> bootloader-related cleanups and refactors:
>
> https://salsa.debian.org/live-team/live-build/merge_requests/19

1) What is the rationale behind removing the --templates option
explanation on manpage?

Do you remove it in any of your commits? Which one?
Or someone else did remove it?

Thank you.

Note: I will make more comments about this bug later in the week.

adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/

Reply | Threaded
Open this post in threaded view
|

Bug#922251: live-build: support syslinux-efi as (additional) bootloader

Matthijs Kooijman-3
Hi Adrian,

> 1) What is the rationale behind removing the --templates option
> explanation on manpage?
I wondered about this option and looked around the source for it, but
could not find any implementation for it, so it seemed good to remove
the documentation for it.

Prompted by your question, I looked a bit further and found that it was
indeed removed:

https://salsa.debian.org/live-team/live-build/commit/7e633e77f24b6f5ab9a8b22d7d6cf6521454d638

> Note: I will make more comments about this bug later in the week.
Thanks!

Gr.

Matthijs

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#922251: live-build: support syslinux-efi as (additional) bootloader

adrian15
El 10/04/19 a las 09:58, Matthijs Kooijman escribió:

> Hi Adrian,
>
>> 1) What is the rationale behind removing the --templates option
>> explanation on manpage?
> I wondered about this option and looked around the source for it, but
> could not find any implementation for it, so it seemed good to remove
> the documentation for it.
>
> Prompted by your question, I looked a bit further and found that it was
> indeed removed:
>
> https://salsa.debian.org/live-team/live-build/commit/7e633e77f24b6f5ab9a8b22d7d6cf6521454d638

In that case IMO that commit should be in its own pull request and not
the current one.

That way it can opt to be applied inmediately while the rest of your
commits is being studied.

adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/

Reply | Threaded
Open this post in threaded view
|

Bug#922251: live-build: support syslinux-efi as (additional) bootloader

Thierry-9
In reply to this post by Matthijs Kooijman-3
Dear Matthijs,

thanks a lot for your work on syslinux-efi, i am relying on syslinux for
Sage Debian Live [1], and more and more laptops are not able to boot on
legacy (bios) formatted devices (including macs).

Is there a chance that this work will be part of buster live-build
package, or is it too late already ?

Ciao,
Thierry

[1] https://sagedebianlive.metelu.net/




On Wed, Apr 10, 2019 at 09:58:54AM +0200, Matthijs Kooijman wrote:

> Hi Adrian,
>
> > 1) What is the rationale behind removing the --templates option
> > explanation on manpage?
> I wondered about this option and looked around the source for it, but
> could not find any implementation for it, so it seemed good to remove
> the documentation for it.
>
> Prompted by your question, I looked a bit further and found that it was
> indeed removed:
>
> https://salsa.debian.org/live-team/live-build/commit/7e633e77f24b6f5ab9a8b22d7d6cf6521454d638
>
> > Note: I will make more comments about this bug later in the week.
> Thanks!
>
> Gr.
>
> Matthijs

12