On Mon, 2013-06-03 at 17:24 +0100, Matthew Garrett wrote: > On Mon, Jun 03, 2013 at 09:18:06AM -0700, James Bottomley wrote: > > > I don't entirely buy that. All EFI programs run with the physical > > address map, therefore every API an EFI program uses is also tested, at > > boot time only, obviously. > > That seems optimistic. Windows never calls QueryVariableInfo() during > boot services, so what makes you think doing so has ever been tested? It's used by the UEFI shell package ... every system which boots to the shell automatically tests this. I know no locked down UEFI system ships with a shell but almost every system in test has a Shell in some form, so I think its fairly safe to call it from boot services. > > However, the ExitBootServices() code seems to be much simpler, so I > > don't think it will cause too many bugs. The UEFI test suites also > > seem to try UEFI calls before and after ExitBootServices(), so I think > > relying on a 1:1 mapping looks safer to me. > > I have no expectation that the majority of system vendors run the test > suite, but I have every expectation that every system vendor runs > Windows. We should behave as close to the tested mechanism as possible, > ie do what Windows does - and that includes calling > SetVirtualAddressMap(). OK, so we basically agree to disagree. When I looked at the actual SetVirtualAddressMap() implementation, my heart skipped several beats: it's a massive set of pointer chasing heuristics which is bound to be incorrect in some instance, just because its so complex and easy to get wrong. Every time it's incorrect, we'll get a physical pointer used in a virtual space and an oops within the UEFI code. Conversely, I think the engineering risk that a particular UEFI call is expecting to have had SetVirtualAddressMap called is much lower. However, what about a compromise: why don't we implement 1:1 mapping and then call SetVirtualAddressMap with the 1:1 map ... in theory the pointer chases should then be nops (it will be replacing the physical address with the same virtual address), so everything should just work and anything the UEFI vendor missed will still work because the physical address will work also in this scenario. James -- 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
