[syslinux] SysLinux Development Questions

Gene Cumm gene.cumm at gmail.com
Sun Jan 11 17:46:56 PST 2015


On Sun, Jan 11, 2015 at 6:12 PM, r0m30 <r0m30 at r0m30.com> wrote:
> Hello,
>
> I'm thinking of using sysliux as the basis for a TCG OPAL Pre-Boot
> Authorization program (COM32 module). I can add AHCI and SATA support
> in a COM32 module to implement IDENTIFY, iF-SEND and IF-RECV, but my
> understanding of syslinux falls short in several areas.
>
> I have a few questions that I would like to ask:
>
> com32 modules in UEFI 64bit mode:
> The AHCI and SATA memory layouts have a lot of memory address
> structures that are broken into two 32bit fields (an upper and lower
> address field) this isn't an issue for the bios COM32 modules as they
> run in 32bit mode and malloc returns 32bit memory allocations.
> However when the 64bit uefi build pass runs there are multiple
> warnings about forcing pointers into 32bit fields and I would also
> assume that malloc is free to return storage above the 32bit
> addressable range. Is lmalloc the solution to keeping allocated memory
> in 32bit addressable storage?  A grep gives me HEAP_LOWMEM parameter

lmalloc is to keep addresses in the lowest 1 MiB, not the lowest 4GiB.
UEFI should essentially have 0 use of lmalloc..

> for lmalloc but that is just an enum without explanation and I can't
> see how/where this changes the memory allocation in malloc.c
>
> Syslinux shared libraries:
> As part of the PBA process the disk image presented to syslinux will
> change completely.  Once the drive is unlocked, the "shadow mbr" is
> replaced with the real disk drive image which will almost certainly
> not match the layout/structure of the booted disk image.  Are the
> shared libraries loaded into and kept in memory once they are
> referenced?  If not is there a way to force my com32 module to be
> statically linked?

Yes, once loaded to memory, library COM32 modules should stay in RAM.
Will the data in the "current" partition change?  Obviously if this
occurs, further disk access will probably be "corrupt".

> chainloading:
> I should be able to use syslinux "chainload the boot drive" for bios
> implementations, but looking at the archives it appears that there is
> currently no chainloading for UEFI support.  Can anyone point me at
> doc or possible starting points for adding UEFI chainloading to
> syslinux? Rebooting will work but is a terrible user experience.

There is no such thing as chainloading a drive in UEFI.  It's only
loading another UEFI binary (not yet functional in Syslinux as of
6.03) or another kernel (Linux, DOS, etc).  Since you're invalidating
all file system information, you'll likely need to load this first,
call back to the UEFI system to try again, or manually scan the
partition table and file system for your binary's blocks.

--
-Gene


More information about the Syslinux mailing list