[syslinux] Embedding com32 modules and ldlinux.sys into one file

[Tal Lubko]

> -----Original Message-----
> From: Gene Cumm [mailto:gene.cumm at gmail.com]
> Sent: Wednesday, January 20, 2016 1:14 PM
> To: Tal Lubko
> Cc: H. Peter Anvin; For discussion of Syslinux and tftp-hpa
> Subject: Re: [syslinux] Embedding com32 modules and ldlinux.sys into
> one file
> 
> On Wed, Jan 20, 2016 at 2:05 AM, H. Peter Anvin via Syslinux
> <syslinux at zytor.com> wrote:
> > On January 19, 2016 12:24:50 PM PST, Tal Lubko <tallubko at yahoo.com>
> wrote:
> >>
> >>
> >>> -----Original Message-----
> >>> From: H. Peter Anvin [mailto:hpa at zytor.com]
> >>> Sent: Tuesday, January 19, 2016 9:17 PM
> >>> To: Tal Lubko; 'Celelibi'
> >>> Cc: 'For discussion of Syslinux and tftp-hpa'
> >>> Subject: Re: [syslinux] Embedding com32 modules and ldlinux.sys
> into
> >>> one file
> >>>
> >>> On 01/19/16 00:07, Tal Lubko via Syslinux wrote:
> >>> >
> >>> > To summarize the answers, the option I see now are:
> >>> >
> >>> > 1) Exposing the bootloader in the BIOS as a (readonly) disk drive
> >>> using standard BIOS or EFI interfaces (hpa suggestion).
> >>> > This suggestion looks very promising. It probably requires some
> >>> changes in the BIOS. I'm not sure if it requires changes in the
> >>> bootloader.
> >>> > There is one potential problem I see: the bootloader is stored on
> >>> some flashrom chip and the Linux image is stored on a different
> >>storage
> >>> device.
> >>> > I think that right now the bootloader assumes they are stored on
> >>the
> >>> same storage device. Am I wrong?
> >>> > If I'm wrong, how do I tell the bootloader to load the Linux
> image
> >>> from a different storage device?
> >>> >
> >>>
> >>> Why do you need this?  This seems like a strange requirement.
> >>>
> >>> Why?  Because you want as much of the boot loader to be upgradable;
> >>> this is a major reason why doing as little in the hard-to-upgrade
> >>BIOS
> >>> makes sense.  If you have another storage device, why not use it?
> >>>
> >>>      -hpa
> >>>
> >>
> >>Hi
> >>Security.
> >>Tal
> >
> > I think you might find that security concern seriously misguided.  In
> fact, there probably is no meaningful security objective that this
> fulfills.
> >
> > Secure boot is technically complicated, and again, you may want to
> simply invoke the Merkel directly as an EFI executable.
> 
> I agree with HPA that there's likely nothing this accomplishes.
> Burning the boot loader into the system firmware chip (BIOS or UEFI)
> means it's now difficult to tune/upgrade, not protected from changes.
> 
> Security is a broad topic.  It's about protecting _something_ from
> _who/what_ doing _an_action_ and/or observing when it might occur.
> 
> --
> -Gene

Hi

The bootloader will be protected from changes because it will be burned to a flash which is read only (by hardware).
That doesn't mean there can't be some other security holes...

I will check about loading the kernel as EFI executable.

Thanks again for your help,
Tal