On 22 February 2016 at 17:09, Mark Rutland [off-list ref] wrote:

On Mon, Feb 22, 2016 at 04:56:57PM +0100, Ard Biesheuvel wrote:

quoted

On 22 February 2016 at 16:43, Mark Rutland [off-list ref] wrote:

quoted

On Mon, Feb 22, 2016 at 03:59:39PM +0100, Ard Biesheuvel wrote:

quoted

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.

Runtime services drivers must call ConvertPointer() to translate the
pointer variables in their global state to their virtual equivalents.
So unless a Runtime driver does not have such state at all, it needs
access to the runtime services table, which is usually retrieved
through the system table. So yes, you're right. And yes, it's moot :-)

quoted

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.

quoted

quoted

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.