Re: [Xen-devel] [PATCH v2 05/12] x86emul: use eflags definitions in x86-defns.h

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Tue, Jan 31, 2017 at 05:56:38AM -0700, Jan Beulich wrote:
> >>> On 31.01.17 at 12:08, <wei.liu2@xxxxxxxxxx> wrote:
> > @@ -5016,20 +5004,20 @@ x86_emulate(
> >  
> >          /*
> >           * SYSCALL (unlike most instructions) evaluates its singlestep 
> > action
> > -         * based on the resulting EFLG_TF, not the starting EFLG_TF.
> > +         * based on the resulting X86_EFLAGS_TF, not the starting 
> > X86_EFLAGS_TF.
> >           *
> >           * As the #DB is raised after the CPL change and before the OS can
> >           * switch stack, it is a large risk for privilege escalation.
> >           *
> > -         * 64bit kernels should mask EFLG_TF in MSR_FMASK to avoid any
> > +         * 64bit kernels should mask X86_EFLAGS_TF in MSR_FMASK to avoid 
> > any
> >           * vulnerability.  Running the #DB handler on an IST stack is also 
> > a
> >           * mitigation.
> >           *
> > -         * 32bit kernels have no ability to mask EFLG_TF at all.  Their 
> > only
> > -         * mitigation is to use a task gate for handling #DB (or to not use
> > -         * enable EFER.SCE to start with).
> > +         * 32bit kernels have no ability to mask X86_EFLAGS_TF at all.
> > +         * Their only mitigation is to use a task gate for handling
> > +         * #DB (or to not use enable EFER.SCE to start with).
> 
> Please use EFLAGS.TF instead here, matching e.g. EFER.SCE.
> 

Fixed.

> With this taken care of and the #include style matching whatever
> is chosen as the final model in the earlier patch,
> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
> However, I'd appreciate if you took the opportunity to add blanks
> around binary operators as mandated by our coding style, on the
> lines that you touch anyway.
> 

The only place I can think of is the bitwise or '|', I will add blanks
around that.

Wei.

> Jan
> 

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