Andy Lutomirski writes:
> On Wed, Jul 1, 2020 at 8:42 AM Brian Gerst wrote:
> > On Fri, Jun 26, 2020 at 1:30 PM Andy Lutomirski wrote:
>> >
>> > The SYSENTER frame setup was nonsense. It worked by accident
>> > because the normal code into which the Xen asm jumped
>> >
On Wed, Jul 1, 2020 at 8:42 AM Brian Gerst wrote:
>
> On Fri, Jun 26, 2020 at 1:30 PM Andy Lutomirski wrote:
> >
> > The SYSENTER frame setup was nonsense. It worked by accident
> > because the normal code into which the Xen asm jumped
> > (entry_SYSENTER_32/compat) threw away SP without
On Fri, Jun 26, 2020 at 1:30 PM Andy Lutomirski wrote:
>
> The SYSENTER frame setup was nonsense. It worked by accident
> because the normal code into which the Xen asm jumped
> (entry_SYSENTER_32/compat) threw away SP without touching the stack.
> entry_SYSENTER_compat was recently modified
On 6/26/20 1:21 PM, Andy Lutomirski wrote:
> The SYSENTER frame setup was nonsense. It worked by accident
> because the normal code into which the Xen asm jumped
> (entry_SYSENTER_32/compat) threw away SP without touching the stack.
> entry_SYSENTER_compat was recently modified such that it
The SYSENTER frame setup was nonsense. It worked by accident
because the normal code into which the Xen asm jumped
(entry_SYSENTER_32/compat) threw away SP without touching the stack.
entry_SYSENTER_compat was recently modified such that it relied on
having a valid stack pointer, so now the Xen
