Syslinux - Jan 2016 - Embedding com32 modules and ldlinux.sys into one file

> -----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

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.
-- 
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.

On 20.01.2016 08:05, H. Peter Anvin via Syslinux 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.
> 

You probably want to write - "to simply invoke the *Kernel* directly as an
EFI executable.

https://www.kernel.org/doc/Documentation/efi-stub.txt

"On the x86 and ARM platforms, a kernel zImage/bzImage can masquerade
as a PE/COFF image, thereby convincing EFI firmware loaders to load
it as an EFI executable."

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