Re: [Xen-devel] EFI GetNextVariableName crashes when running under Xen, but not under Linux. efi-rs=0 works. No memmap issues

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Wed, Jan 28, 2015 at 08:40:44AM +0000, Jan Beulich wrote:
> >>> On 27.01.15 at 19:20, <konrad.wilk@xxxxxxxxxx> wrote:
> > On Tue, Jan 27, 2015 at 04:17:05PM +0000, Jan Beulich wrote:
> >> Again - apart from mapping the range, did you also make sure it
> >> didn't get passed to the allocator (and hence couldn't have got
> >> overwritten)?
> > 
> > Yes, see patch:
> 
> Oh, sorry, I must have not looked closely enough.
> 
> > Also see attached of the code with what Linux sees and what Xen sees
> > (Linux first).
> 
> Indeed this
> 
>   8b: 44 38 2d c2 10 00 00    cmp    %r13b,0x10c2(%rip)        # 0x115 [01 01 
> 00 00 00 00 00 00][00 01 00 00 00 00 00 00
>   92: 75 12                   jne    0xa6
> 
> causes the code in question to be skipped under Linux.
> 
> > I am thinking that the firmware is under the assumption
> > that if SetVirtualAddressMap is not called then you MUST be still
> > before ExitBootServices has been called. Going to verify that by
> > implementing an GetNextVariableName before calling ExitBootServices)
> 
> Not sure how exactly you envision to do this, but I'm having a hard
> time seeing how this would prove anything, in particular because
> calling runtime services functions prior to exiting boot services must
> be possible anyway.

And it works - one of the patches implements an routine to call the
dreaded function before ExitBootServices and it works nicely (ie - I
see:

Xen 4.6-unstable (c/s Tue Jan 27 14:05:36 2015 -0500 git:332c049-dirty) EFI 
loader
Using configuration file 'xen.cfg'
vmlinuz-3.19.0-rc4+: 0x00000000cf81a000-0x00000000cfda5f90
initramfs-3.19.0-rc4+.img: 0x00000000cb522000-0x00000000cd7b04d3
GetNextVariableName: 
0x8be4df610x93ca0x11d20xaa0xd0x00xe00x980x30x2b0x8c:SimpleBootFlag 0x0
0x5e724c0c0x5c030x45430xbc0xb60xc10xe20x3d0xe20x410x36:TpmSaveState 0x0
0x6403753b0xabde0x4da20xaa0x110x690x830xef0x2a0x7a0x69:TpmAcpiData 0x0
0x8be4df610x93ca0x11d20xaa0xd0x00xe00x980x30x2b0x8c:SetupMode 0x0
0x8be4df610x93ca0x11d20xaa0xd0x00xe00x980x30x2b0x8c:SecureBoot 0x0
0xe5bbf7be0x24170x499b0x970xdb0x390xf40x890x630x910xbc:BuildDate 0x0
Could not get next variable


It is just that making that call after ExitBootServices does not
work. But on Linux the extra mix is that we also call 'SetVirtualAddressMap'
which we do not do.
> 
> And iirc you had already tried calling the function prior to doing much
> else (namely, prior to loading Dom0), and it still crashed? Did you

Yes, it did crash. That is - we call it _after_ calling ExitBootServices.

> investigate when the memory type of that region changes (in an
> earlier mail you said dmem from the EFI shell reported it as Boot
> Services, albeit it's not fully clear what that tagging is supposed to
> be telling us)?

It did not help. Having the mapping of BootServicesData&Code did not
help with the problem. However having disabled the call to
ExitBootServices the mapping of BootServicesData&Code did help - as we
were able to make the proper calls.

In short, I think the firmware has a bug where it makes the assumption
that if SetVirtualAddressMap then BootServices should _not_ be used
 - otherwise it will use it.

I am not really sure of what the work-around should be in Xen except
making SetVirtualAddressMap work..
> 
> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel