lkml.org 
[lkml]   [2014]   [Apr]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*
    On Wed, Apr 23, 2014 at 8:53 AM, H. Peter Anvin <hpa@zytor.com> wrote:
    > On 04/23/2014 02:54 AM, One Thousand Gnomes wrote:
    >>> Ideally the tests should be doable such that on a normal machine the
    >>> tests can be overlapped with the other things we have to do on that
    >>> path. The exit branch will be strongly predicted in the negative
    >>> direction, so it shouldn't be a significant problem.
    >>>
    >>> Again, this is not the case in the current prototype.
    >>
    >> Or you make sure that you switch to those code paths only after software
    >> has executed syscalls that make it possible it will use a 16bit ss.
    >>
    >
    > Which, again, would introduce a race, I believe, at least if we have an
    > LDT at all (and since we only enter these code paths for LDT descriptors
    > in the first place, it is equivalent to the current code minus the filters.)

    The only way I can see to trigger the race is with sigreturn, but it's
    still there. Sigh.

    Here are two semi-related things:

    1. The Intel manual's description of iretq does seems like it forgot
    to mention that iret restores the stack pointer in anything except
    vm86 mode. Fortunately, the AMD manual seems to thing that, when
    returning *from* 64-bit mode, RSP is always restored, which I think is
    necessary for this patch to work correctly.

    2. I've often pondered changing the way we return *to* CPL 0 to bypass
    iret entirely. It could be something like:

    SS
    RSP
    EFLAGS
    CS
    RIP

    push 16($rsp)
    popfq [does this need to force rex.w somehow?]
    ret $64

    This may break backtraces if cfi isn't being used and we get an NMI
    just before the popfq. I'm not quite sure how that works.

    I haven't benchmarked this at all, but the only slow part should be
    the popfq, and I doubt it's anywhere near as slow as iret.

    >
    >> The other question I have is - is there any reason we can't fix up the
    >> IRET to do a 32bit return into a vsyscall type userspace page which then
    >> does a long jump or retf to the right place ?
    >
    > I did a writeup on this a while ago. It does have the problem that you
    > need additional memory in userspace, which is per-thread and in the
    > right region of userspace; this pretty much means you have to muck about
    > with the user space stack when user space is running in weird modes.
    > This gets complex very quickly and does have some "footprint".
    > Furthermore, on some CPUs (not including any recent Intel CPUs) there is
    > still a way to leak bits [63:32]. I believe the in-kernel solution is
    > actually simpler.
    >

    There's also no real guarantee that user code won't unmap the vdso.

    --Andy


    \
     
     \ /
      Last update: 2014-04-23 20:01    [W:2.202 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site