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

[mark.rutland@arm.com (Mark Rutland)]

[...]

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

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

Thanks,
Mark.