On Fri, Oct 10, 2014 at 02:27:46PM +0100, Ard Biesheuvel wrote: > On 10 October 2014 15:03, Mark Rutland <mark.rutland@xxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
