On Thu, Mar 23, 2017 at 05:25:51PM +0000, Maxime Villard wrote:
> Module Name:  src
> Committed By: maxv
> Date:         Thu Mar 23 17:25:51 UTC 2017
> Modified Files:
>       src/sys/arch/amd64/amd64: locore.S machdep.c trap.c
> Log Message:
> Remove this call gate on amd64, it is useless and vulnerable.
> Call gates do not modify %rflags, so interrupts are not disabled when
> entering the gate. There is a small window where we are in kernel mode and
> with a userland %gs, and if an interrupt happens here we will rejump into
> the kernel but not switch to the kernel TLS.
> Userland can simply perform a gate call in a loop, and hope that at some
> point an interrupt will be received in this window - which necessarily will
> be the case. With a specially-crafted %gs it is certainly enough to
> escalate privileges.
> To generate a diff of this commit:
> cvs rdiff -u -r1.121 -r1.122 src/sys/arch/amd64/amd64/locore.S
> cvs rdiff -u -r1.253 -r1.254 src/sys/arch/amd64/amd64/machdep.c
> cvs rdiff -u -r1.94 -r1.95 src/sys/arch/amd64/amd64/trap.c


I see in arch/i386/i386/locore.S that there is another call gate and

1246 IDTVEC(osyscall)
1247 #ifndef XEN
1248         /* XXX we are in trouble! interrupts be off here. */
1249         cli                     /* must be first instruction */
1250 #endif
1251         pushfl                  /* set eflags in trap frame */

Is 'cli' as first instruction what should've been done here, if it
wasn't been otherwise useless? can xen not do it?


Reply via email to