Jan Beulich
2007-Jun-22 15:01 UTC
[Xen-devel] [PATCH] x86-64: clear DF for kernel when forwarding syscall
While this is not really matching native behavior, no guest seems to assume EFLAGS.DF being set or reflecting application state. Thus clear it for now, the syscall/sysenter patch that I''ll hopefully be able to get to work will then introduce a more consistent solution. In any case, without this any app can easily force kernel data corruption. Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: 2007-06-18/xen/arch/x86/x86_64/entry.S ==================================================================--- 2007-06-18.orig/xen/arch/x86/x86_64/entry.S 2007-06-22 16:35:55.000000000 +0200 +++ 2007-06-18/xen/arch/x86/x86_64/entry.S 2007-06-22 16:36:59.000000000 +0200 @@ -34,6 +34,7 @@ switch_to_kernel: jnc 1f movb $TBF_INTERRUPT,TRAPBOUNCE_flags(%rdx) 1: call create_bounce_frame + andl $~X86_EFLAGS_DF,UREGS_eflags(%rsp) jmp test_all_events /* %rbx: struct vcpu, interrupts disabled */ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2007-Jun-23 16:22 UTC
Re: [Xen-devel] [PATCH] x86-64: clear DF for kernel when forwarding syscall
Thanks. By the way, I''ve been thinking that rather than rev''ing the paravirtual hypercall interface for specifying syscall/sysenter callback points, since these have a direct native equivalent that we''re trying to emulate the semantics of as closely as possible then we may as well emulate the MSRs for specifying RIP/RFLAGS_mask/etc too. Callers can catch the #GP to detect whether the new MSR-based interface is supported, and/or we can add a feature flag in our CPUID leaves. -- Keir On 22/6/07 16:01, "Jan Beulich" <jbeulich@novell.com> wrote:> While this is not really matching native behavior, no guest seems to assume > EFLAGS.DF being set or reflecting application state. Thus clear it for now, > the syscall/sysenter patch that I''ll hopefully be able to get to work will > then introduce a more consistent solution. In any case, without this any > app can easily force kernel data corruption. > > Signed-off-by: Jan Beulich <jbeulich@novell.com> > > Index: 2007-06-18/xen/arch/x86/x86_64/entry.S > ==================================================================> --- 2007-06-18.orig/xen/arch/x86/x86_64/entry.S 2007-06-22 16:35:55.000000000 > +0200 > +++ 2007-06-18/xen/arch/x86/x86_64/entry.S 2007-06-22 16:36:59.000000000 +0200 > @@ -34,6 +34,7 @@ switch_to_kernel: > jnc 1f > movb $TBF_INTERRUPT,TRAPBOUNCE_flags(%rdx) > 1: call create_bounce_frame > + andl $~X86_EFLAGS_DF,UREGS_eflags(%rsp) > jmp test_all_events > > /* %rbx: struct vcpu, interrupts disabled */ > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jan Beulich
2007-Jun-24 10:58 UTC
Re: [Xen-devel] [PATCH] x86-64: clear DF for kernel when forwarding syscall
I had sent a mail to that effect (at least I think I had) - on x86-64, this may be the preferred way (at least for the !XEN_COMPAT case), but the i386 kernel has to remain runnable on 32-bit Xen, and doing gp-fault-recoverable MSR accesses doesn''t buy us anything in terms of not needing specialized Xen code (i.e. if we need special Xen code, we can equally well do hypercalls). For that reason, at this point I implemented both access methods, but haven''t got around yet to make the kernel side use them. Jan>>> Keir Fraser <Keir.Fraser@cl.cam.ac.uk> 06/23/07 6:22 PM >>>Thanks. By the way, I''ve been thinking that rather than rev''ing the paravirtual hypercall interface for specifying syscall/sysenter callback points, since these have a direct native equivalent that we''re trying to emulate the semantics of as closely as possible then we may as well emulate the MSRs for specifying RIP/RFLAGS_mask/etc too. Callers can catch the #GP to detect whether the new MSR-based interface is supported, and/or we can add a feature flag in our CPUID leaves. -- Keir On 22/6/07 16:01, "Jan Beulich" <jbeulich@novell.com> wrote:> While this is not really matching native behavior, no guest seems to assume > EFLAGS.DF being set or reflecting application state. Thus clear it for now, > the syscall/sysenter patch that I''ll hopefully be able to get to work will > then introduce a more consistent solution. In any case, without this any > app can easily force kernel data corruption. > > Signed-off-by: Jan Beulich <jbeulich@novell.com> > > Index: 2007-06-18/xen/arch/x86/x86_64/entry.S > ==================================================================> --- 2007-06-18.orig/xen/arch/x86/x86_64/entry.S 2007-06-22 16:35:55.000000000 > +0200 > +++ 2007-06-18/xen/arch/x86/x86_64/entry.S 2007-06-22 16:36:59.000000000 +0200 > @@ -34,6 +34,7 @@ switch_to_kernel: > jnc 1f > movb $TBF_INTERRUPT,TRAPBOUNCE_flags(%rdx) > 1: call create_bounce_frame > + andl $~X86_EFLAGS_DF,UREGS_eflags(%rsp) > jmp test_all_events > > /* %rbx: struct vcpu, interrupts disabled */ > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2007-Jun-24 22:02 UTC
Re: [Xen-devel] [PATCH] x86-64: clear DF for kernel when forwarding syscall
On 24/6/07 11:58, "Jan Beulich" <jbeulich@novell.com> wrote:> I had sent a mail to that effect (at least I think I had) - on x86-64, this > may > be the preferred way (at least for the !XEN_COMPAT case), but the i386 > kernel has to remain runnable on 32-bit Xen, and doing gp-fault-recoverable > MSR accesses doesn''t buy us anything in terms of not needing specialized > Xen code (i.e. if we need special Xen code, we can equally well do > hypercalls). > For that reason, at this point I implemented both access methods, but haven''t > got around yet to make the kernel side use them.The only problem is it probably requires an entirely new top-level hypercall because it''s not going to fit into the constraints of the existing callback_op(). -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jan Beulich
2007-Jun-25 10:37 UTC
Re: [Xen-devel] [PATCH] x86-64: clear DF for kernel when forwarding syscall
>>> Keir Fraser <Keir.Fraser@cl.cam.ac.uk> 06/25/07 12:02 AM >>> >On 24/6/07 11:58, "Jan Beulich" <jbeulich@novell.com> wrote: > >> I had sent a mail to that effect (at least I think I had) - on x86-64, this >> may >> be the preferred way (at least for the !XEN_COMPAT case), but the i386 >> kernel has to remain runnable on 32-bit Xen, and doing gp-fault-recoverable >> MSR accesses doesn''t buy us anything in terms of not needing specialized >> Xen code (i.e. if we need special Xen code, we can equally well do >> hypercalls). >> For that reason, at this point I implemented both access methods, but haven''t >> got around yet to make the kernel side use them. > >The only problem is it probably requires an entirely new top-level hypercall >because it''s not going to fit into the constraints of the existing >callback_op().Why? The flags mask can be put in the offset/address field, and there''s nothing preventing the guest from putting NULL or even garbage in the selector field on 32-bits. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel