On 06/03/2024 10:49 am, Jan Beulich wrote: > On 06.03.2024 11:33, Andrew Cooper wrote: >> On 05/03/2024 2:04 pm, Jan Beulich wrote: >>> --- a/xen/arch/x86/x86_64/entry.S >>> +++ b/xen/arch/x86/x86_64/entry.S >>> @@ -52,7 +52,7 @@ UNLIKELY_END(syscall_no_callback) >>> movq %rax,TRAPBOUNCE_eip(%rdx) >>> movb %cl,TRAPBOUNCE_flags(%rdx) >>> call create_bounce_frame >>> - andl $~X86_EFLAGS_DF,UREGS_eflags(%rsp) >>> + andb $~(X86_EFLAGS_DF >> 8), UREGS_eflags + 1(%rsp) >> The other adjustments are fine, but what on earth are we doing with DF here? >> >> This looks straight up buggy. We've got no legitimate reason to be >> playing with the guest's view of DF. > This is the PV equivalent of the SYSCALL_MASK MSR, isn't it?
Well, is it? It definitely never existed in 32bit builds of Xen, when the int80 direct trap existed. I don't see any evidence of it applying anywhere for compat PV guests either, even those with syscall enabled. > With it not > really being an (emulated) MSR, but an agreement that guests will only ever > care about having DF cleared (besides the requested way of dealing with the > event mask). One of the many things not written down anywhere ... If it's not written down, it doesn't exist... And even if this is supposed to be a PV-FMASK-ish thing, it's buggy because it apples also when #UD is raised for no registered callback. (And yes, I realise there is a chronology issues here (the #UD check is the newer element), but it really will corrupt state as presented in a SIGSEGV frame. The question we need to answer is whether there is any remotely-credible way that a PV guest kernel author could be expecting this behaviour and relying on it. I honestly don't think there is. It fails the principle of least surprise compared to native behaviour, 32bit PV behaviour, and to every non-SYSCALL based 64bit event also. It either needs writing down somewhere (and the #UD case fixing), or it needs deleing, because continuing to leave it in this state isn't ok. ~Andrew
