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

[H. Peter Anvin]

On January 23, 2016 12:13:56 PM PST, Tal Lubko <tallubko at yahoo.com> wrote:
>
>
>> -----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

All that means is that you won't be able to fix your bootloader when it has bugs, security or otherwise.
-- 
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.