On Mon, Feb 22, 2016 at 04:56:57PM +0100, Ard Biesheuvel wrote: > On 22 February 2016 at 16:43, Mark Rutland <mark.rutland@xxxxxxx> wrote: > > On Mon, Feb 22, 2016 at 03:59:39PM +0100, Ard Biesheuvel wrote: > >> The permanent, writable mapping of the UEFI System table is only > >> referenced during invocations of UEFI Runtime Services, at which time > >> the UEFI virtual mapping is available, which also covers the system > >> table (since the runtime services themselves need access to it) > > > > I'm not sure it's strictly true that the runtime services themselves > > need access to the system table. Why would that be necessary? Are > > runtime services mandated to indirect calls via the system table? > > > > They don't need access per se, but they are allowed to reference it, > and so the memory remapping layer must make it accessible after > SetVirtualAddressMap(). The spec lists explicitly which fields are > still valid after ExitBootServices() I was language-lawyering ;) I appreciate that they _can_, I just didn't think it was true that they _must_ (i.e. that they always "need to access it"). Per the below that's likely moot. > SetVirtualAddressMap() is a runtime service, and one of the things it > does is update the pointers in the system table, hence it must be > located in RuntimeService memory, because anything else may be gone by > this time. Good point. That does imply that it must be in EfiRuntimeServices* memory. > > From the spec, I couldn't find a mandate that the system table (nor the > > runtime services table) were in a region of EfiRuntimeServicesData > > memory. I suspect I'm looking in the wrong place... > > We should clarify it if it is not clear (or if I turn out to be wrong) I'm hoping that I've simply missed something. Perhaps the implication above was intentional, albeit rather opaque. Otherwise, I certainly agree a clarification would be a good thing! 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
