Gene Cumm
2016-Jan-20 11:13 UTC
[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
Tal Lubko
2016-Jan-23 20:13 UTC
[syslinux] Embedding com32 modules and ldlinux.sys into one file
> -----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. > > -- > -GeneHi 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
H. Peter Anvin
2016-Jan-23 20:17 UTC
[syslinux] Embedding com32 modules and ldlinux.sys into one file
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, >TalAll 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.
Seemingly Similar Threads
- Embedding com32 modules and ldlinux.sys into one file
- Embedding com32 modules and ldlinux.sys into one file
- Embedding com32 modules and ldlinux.sys into one file
- Embedding com32 modules and ldlinux.sys into one file
- Embedding com32 modules and ldlinux.sys into one file