lkml.org 
[lkml]   [2019]   [Dec]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRE: [PATCH] x86: Remove force_iret()
    Date
    From: Brian Gerst
    > Sent: 20 December 2019 12:18
    ...
    > > Is it ever possible for any of the segment registers to refer to the LDT
    > > and for another thread to invalidate the entries 'very late' ?
    > > So even though the values were valid when changed, they are
    > > invalid during the 'return to user' sequence.
    >
    > Not in the SYSRET case, where the kernel requires that CS and SS are
    > static segments in the GDT. Any userspace context that uses LDT
    > segments for CS/SS must return with IRET. There is fault handling for
    > IRET (fixup_bad_iret()) for this case.

    Ok - It is a long time since i looked at these 'syscall' instructions.

    ...
    > > Is it actually cheaper to properly validate the segment registers,
    > > or take the 'hit' of the slightly slower IRET path and get the cpu
    > > to do it for you?
    >
    > SYSRET is faster because it avoids segment table lookups and
    > permission checks for CS and SS. It simply sets the selectors to
    > values set in an MSR and the attributes (base, limit, etc.) to fixed
    > values. It is up to the OS to make sure the actual segment
    > descriptors in memory match those default attributes.

    I wonder how much difference that make when 'page table separation'
    is used?

    I guess the loading of ds/es/fs/gs can fault - but that it no harder
    to handle than in the IRET case.

    David

    Anyway, off until the new year now.

    -
    Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
    Registration No: 1397386 (Wales)
    \
     
     \ /
      Last update: 2019-12-20 13:36    [W:4.715 / U:0.068 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site