Re: [RFC/PATCH 2/3] x86/signal/64: Try to preserve hardware SS across 64-bit signal delivery

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Aug 13, 2015 at 1:25 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote:
> On Thu, Aug 13, 2015 at 1:18 PM, Andy Lutomirski <luto@xxxxxxxxxx> wrote:
>> Linux used to have nearly useless SS handling for 64-bit signals.  Signal
>> delivery to a 64-bit process would preserve the SS selector, but the
>> selector wasn't saved in sigcontext.  Sigreturn would then clobber SS.
>> If the signal being delivered was due to a bad SS, signal delivery would
>> fail and the task would be killed.
>>
>> As of Linux 4.1, it's fixed: signal delivery sets up a valid SS in the
>> hardware SS selector, saves the old SS in the sigcontext, and restores it
>> properly in sigreturn.
>>
>> DOSEMU had a curious workaround for the old behavior: it saved the
>> hardware SS selector it was given during signal delivery and fudged
>> RIP and CS so that sigreturn would return to a trampoline that
>> restored the old RIP, CS, and, importantly, SS.
>>
>> The upshot is that the change in sigcontext had no effect on DOSEMU
>> (DOSEMU doesn't care what was in sigcontext, and the fact that the
>> old SS is presented to the trampoline in new kernels is irrelevant
>> because the trampoline uses long mode), but the change in signal
>> delivery caused DOSEMU's workaround to restore __USER_DS instead of
>> the correct pre-signal SS value.
>>
>> Do our best to work around it: explicitly check whether the old SS
>> is usable and leave it alone during signal delivery if it is.
>> Sigreturn is unchanged.
>>
>> Reported-by: Stas Sergeev <stsp@xxxxxxx>
>> Fixes: c6f2062935c8 ("x86/signal/64: Fix SS handling for signals delivered to 64-bit programs")
>> Signed-off-by: Andy Lutomirski <luto@xxxxxxxxxx>
>> ---
>
>> +               asm ("lar %[old_ss], %[ar]\n\t"
>> +                    "jz 1f\n\t"
>> +                    "xorl %[ar], %[ar]\n\t"    /* If invalid, set ar = 0 */
>> +                    "1:"
>> +                    : [ar] "=r" (ar)
>> +                    : [old_ss] "rm" ((u16)regs->ss));
>> +
>
> Now that I sent this...
>
> I should learn to think very carefully before doubting Linus'
> off-the-cuff intuition about the x86 instruction set.  This can use
> VERW after all, as long as it's careful to set RPL==3.

And the corollary to that is: I should also assume that Linus is out
to get me :)

VERW is no good, because it considers non-present segments to be
writable.  Test cases for the win!

--Andy
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux