lkml.org 
[lkml]   [2019]   [Nov]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    Subject[PATCH 2/2] x86/Xen/32: simplify xen_iret_crit_fixup's ring check
    From
    Date
    This can be had with two instead of six insns, by just checking the high
    CS.RPL bit.

    Also adjust the comment - there would be no #GP in the mentioned cases,
    as there's no segment limit violation or alike. Instead there'd be #PF,
    but that one reports the target EIP of said branch, not the address of
    the branch insn itself.

    Signed-off-by: Jan Beulich <jbeulich@suse.com>
    ---
    An alternative would be to keep using SEGMENT_RPL_MASK, but follow it
    with "jpe".

    --- a/arch/x86/xen/xen-asm_32.S
    +++ b/arch/x86/xen/xen-asm_32.S
    @@ -153,22 +153,15 @@ hyper_iret:
    * it's still on stack), we need to restore its value here.
    */
    ENTRY(xen_iret_crit_fixup)
    - pushl %ecx
    /*
    * Paranoia: Make sure we're really coming from kernel space.
    * One could imagine a case where userspace jumps into the
    * critical range address, but just before the CPU delivers a
    - * GP, it decides to deliver an interrupt instead. Unlikely?
    - * Definitely. Easy to avoid? Yes. The Intel documents
    - * explicitly say that the reported EIP for a bad jump is the
    - * jump instruction itself, not the destination, but some
    - * virtual environments get this wrong.
    + * PF, it decides to deliver an interrupt instead. Unlikely?
    + * Definitely. Easy to avoid? Yes.
    */
    - movl 3*4(%esp), %ecx /* nested CS */
    - andl $SEGMENT_RPL_MASK, %ecx
    - cmpl $USER_RPL, %ecx
    - popl %ecx
    - je 2f
    + testb $2, 2*4(%esp) /* nested CS */
    + jnz 2f

    /*
    * If eip is before iret_restore_end then stack
    \
     
     \ /
      Last update: 2019-11-11 15:33    [W:2.576 / U:0.128 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site