Re: [PATCH v3] arm64/efi: efistub: jump to 'stext' directly, not through the header

[Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>]

On Fri, Oct 10, 2014 at 02:27:46PM +0100, Ard Biesheuvel wrote:
> On 10 October 2014 15:03, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> wrote:
> > [...]
> >
> >> >> > But if the EFI loader is allowed to load stext at the precise start of
> >> >> > RAM (or anywhere not in the idmap), in attempting the copy we'd try to
> >> >> > access unmapped addresses.
> >> >> >
> >> >> > So if that's a possibility, we need to shrink the copy to cover stext
> >> >> > to _edata rather than _text to edata.
> >> >> >
> >> >> > Does that make sense?
> >> >> >
> >> >>
> >> >> That cannot happen. The PE/COFF .text section's positive relative
> >> >> virtual offset ensures that the memory image has room for the header,
> >> >> it's just not guaranteed that anything gets copied there.
> >> >
> >> > Ok. If we're guaranteed to have some space there, we're fine.
> >> >
> >> > I'm probably being a bit thick here, but where is the "positive relative
> >> > virtual offset" in the header? Which field defines that?
> >> >
> >>
> >> The fields VirtualSize, VirtualAddress (the field I was referring to),
> >> SizeOfRawData and PointerToRawData define the relation between the
> >> file layout and the memory layout of the .text section (line 219 and
> >> up in head.S)
> >
> > I guess my confusion is over the semantics of the VirtualAddress field.
> > If it's treated as an offset, what is that offset relative to in memory?
> > And what defines that the space covered by that offset is accessible?
> >
> 
> The PE/COFF spec 8.3 describes VirtualAddress as
> 
> """
> For executable images, the address of the first byte of the section
> relative to the image base when the section is loaded into memory.
> """
> 
> ImageBase is a field itself in the PE/COFF header, described as
> 
> """
> The preferred address of the first byte of image when loaded into
> memory; must be a multiple of 64 K.
> """

Thanks for the info, this now makes a lot more sense to me.

So that means the .text section is not the start of the image, but is
offset by (stext - efi_head) bytes from the start, covering the header
(regardless of whether it is actually present in the loaded image).

> The SizeOfImage field is described as
> 
> """
> The size (in bytes) of the image, including all headers, as the image
> is loaded in memory.
> """
> 
> My interpretation is that memory needs to be allocated for the header
> as well as all sections that have a VirtualSize (including sections
> like BSS which don't have a payload in the file)

That would match what I understand from reading the above, though it
strikes me as odd that space needs to be allocated for the headers if
they aren't guaranteed to be copied -- it's not defined where they would
live in the image.

> >> In our current definition, the memory offset and the file offset are
> >> identical (which this patch redefines as 'stext_offset'). The virtual
> >> size covers the entire static memory footprint of Image (minus the
> >> header). whereas the SizeOfRawData contains the size of the payload in
> >> the file (again, minus the header). The balance is zero initialized by
> >> the loader.
> >
> > I can see why this guarantees there is space for stext to _end, but I
> > don't understand how this guarantees there is a valid mapping for the
> > region that would otherwise be _head to stext.
> >
> 
> The allocation itself is defined in terms of ImageBase/SizeOfImage
> (although ImageBase is only a preferred offset)
> How this allocation is populated with data (and where the holes are)
> is described by the sections.

Ok. Thanks for putting this information together (it's remarkably
useful), and thanks for putting up with my ignorance of PE/COFF.

Cheers,
Mark.