On 2018-11-18 17:13:21, Jordan Justen wrote:
> On 2018-11-18 14:37:09, Andrew Fish wrote:
> >
> >
> > > On Nov 18, 2018, at 4:07 AM, Liu Yu <pedroa....@outlook.com> wrote:
> > >
> > > sorry your path can't fix this issue. if this path just turn off
> > > optimization option within sec.c not global project.
> > >
> > > I have tested different version GCC such as (GCC4,8, GCC5.x, GCC7.x)
> > > and all of them can duplicate this issue (Ubuntu 16.04, 16.10,18.04 )
> > >
> > > I have traced this issue on my hand.
> > >
> > > you can see Dispatcher.c (MdeModulePkg/Pei/DIspatcher/) Line 792:
> > >
> > >
> > > 790 if (StackOffsetPositive) {
> > > 791 SecCoreData = (CONST EFI_SEC_PEI_HAND_OFF *)((UINTN)(VOID
> > > *)SecCoreData + StackOffset);
> > > 792 Private = (PEI_CORE_INSTANCE *)((UINTN)(VOID *)Private +
> > > StackOffset);
> > > 793 } else {
> > > 794 ..........
> > > 795 ..........
> > > 796 }
> > >
> > > 790 --792 disassembly code
> > >
> > > 0x10200f2ca <PeiCheckAndSwitchStack+1030>: test %r14b,%r14b
> > > 0x10200f2cd <PeiCheckAndSwitchStack+1033>: je 0x10200f2df
> > > <PeiCheckAndSwitchStack+1051>
> > > 0x10200f2cf <PeiCheckAndSwitchStack+1035>: mov 0x38(%rsp),%rax
> > > 0x10200f2d4 <PeiCheckAndSwitchStack+1040>: lea 0x0(%rbp,%rax,1),%r14
> > > 0x10200f2d9 <PeiCheckAndSwitchStack+1045>: lea (%rbx,%rax,1),%rbp
> > >
> > > we can see Private value have been stored in %rbp (rbp register be
> > > used as general register ) so when call
> > > TemporaryRamSupportPpi->TemporaryRamMigration()
> > >
> >
> > The calling conventions define RBP as non-volatile must be preserved
> > by callee. Using RBP as the frame pointer is optional.
>
> This is kind of a mess. I think the definition of
> EFI_PEI_TEMPORARY_RAM_SUPPORT_PPI is really to blame. It probably
> should not have been spec'd as 'change stack and return'. Instead, it
> should have been given a new function pointer to switch-stack and call
> into.
Andrew, Mike,
I developed a PEI Core fix for this issue, which Liu Yu verified.
Unfortunately, it involves add assembly code in a key area of the PEI
Core. See the top 2 commits of:
https://github.com/jljusten/edk2/commits/emulator-temp-ram
I only wrote assembly for X64 nasm. But, I notice that neither the PEI
or DXE Core modules include any assembly code. So, I want to make sure
I'm heading in the right direction before working on it further.
As I mentioned below, I think PIWG could consider an new
TemporarayRemSupport interface that might work better, but that also
may not be worth the effort.
Can something like this change be integrated into the PEI Core?
Thanks for your time,
-Jordan
> By returning with a switched stack, we don't really know what the
> returning code could do with regard to the stack. For example, it
> could have saved the stack value on the stack and then pop it into a
> register and somehow switch the stack back to the old stack. It seems
> unlikely, but I don't think anything prevents it.
>
> Additionally, there is the issue of rbp/ebp being used as a frame
> pointer. This can lead to some variables being used from the temp ram
> location after we return from TemporaryRamMigration. (Assuming rbp/ebp
> is not adjusted to point to the new stack.)
>
> So, is it safe to adjust rbp? Unknown. It may not be if rbp is not
> used as a frame pointer. Is it safe to *not* adjust rbp and
> potentially allow the old temp ram stack to be used? Unknown.
>
> Now, if TemporaryRamMigration received a new function to call into, we
> can safely assume that the new stack transition would proceed as
> expected without having to worry if a compiler is using rbp/ebp as a
> framepointer or not.
>
> Another advantage could have been that something like the BasePkg
> SwitchStack function could have been used, hopefully preventing people
> from trying to write error prone assembly code for
> TemporaryRamMigration.
>
> -Jordan
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
