• F
    xen: Fix possible user space selector corruption · 7cde9b27
    Frediano Ziglio 提交于
    Due to the way kernel is initialized under Xen is possible that the
    ring1 selector used by the kernel for the boot cpu end up to be copied
    to userspace leading to segmentation fault in the userspace.
    
    Xen code in the kernel initialize no-boot cpus with correct selectors (ds
    and es set to __USER_DS) but the boot one keep the ring1 (passed by Xen).
    On task context switch (switch_to) we assume that ds, es and cs already
    point to __USER_DS and __KERNEL_CSso these selector are not changed.
    
    If processor is an Intel that support sysenter instruction sysenter/sysexit
    is used so ds and es are not restored switching back from kernel to
    userspace. In the case the selectors point to a ring1 instead of __USER_DS
    the userspace code will crash on first memory access attempt (to be
    precise Xen on the emulated iret used to do sysexit will detect and set ds
    and es to zero which lead to GPF anyway).
    
    Now if an userspace process call kernel using sysenter and get rescheduled
    (for me it happen on a specific init calling wait4) could happen that the
    ring1 selector is set to ds and es.
    
    This is quite hard to detect cause after a while these selectors are fixed
    (__USER_DS seems sticky).
    
    Bisecting the code commit 7076aada appears
    to be the first one that have this issue.
    Signed-off-by: NFrediano Ziglio <frediano.ziglio@citrix.com>
    Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
    Reviewed-by: NAndrew Cooper <andrew.cooper3@citrix.com>
    7cde9b27
smp.c 18.0 KB