Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Andy Lutomirski <luto@amacapital.net>]

On Wed, Aug 19, 2015 at 3:10 AM, Stas Sergeev <stsp@list.ru> wrote:
> 19.08.2015 01:42, Andy Lutomirski пишет:
>> What do you mean lack of proper 32/16 bit support?
> At least the following:
>
> 1. vm86().
> There was a patch:
> http://v86-64.sourceforge.net/
> Afaik rejected by Andi Kleen (likely for a good reason - too complex).
> There is some kvm-based alternative which IIRC was called by dosemu authors
> as "too slow", and so they started to use a jit-compiler. Wine have started
> to use dosbox for the DOS progs AFAIK. So both projects have a work-arounds
> to this limitation with which they are happy, and so it probably not worth
> the re-visiting.
>

Wow!

Yeah, that's quite a hack.  EFI mixed mode support used to play
similar tricks.  Unfortunately, switching in and out of long mode at
runtime works very poorly and has terrible interactions with perf, so
EFI stopped doing that.

> 2. espfix64.
> Its there since 3.16, but dosemu have lots of work-arounds in its code.
> The iret trampoline, for example, uses the carefully aligned stack page,
> where the high word of ESP is zero.
> Another part of the work-around is in a sighandler to decode the
> instruction to figure out what register caused a fault (corrupted esp
> value usually goes into ebp first, then to other regs) and zero out
> the high word of that, plus the high word of esp. There are also other
> bits of the work-around spread around the dosemu code, and I am surprised
> it actually even works!

Wow, no kidding!  At least this is fixed now.

>
> 3. SS problem. Was fixed in some versions of 4.1; not fixed any more. ;)
> dosemu did a glorious iret work-around.
>
> 4. FS problem.
> Worked around by autoconf checks to ban some gcc options, plus some
> special care when accessing thread-local vars in a sighandler.
> While your suggestion is to write an asm handlers, to the date I don't
> think anyone did that. It is easier to work-around it by other means.
> Maybe if you show an example of such handler, the things will change,
> but it is simpler to just wait for a kernel fix IMHO.
>

Something like:

mov $__NR_arch_prctl, %rax
mov $ARCH_GET_FS, %rdi
mov [wherever you safe fsbase], %rsi
syscall
mov $ARCH_SET_FS, %rdi
mov (wherever you stashed glibc's value), %rsi
syscall
pushq $0
call real_signal_handler
popq %rax
mov $__NR_arch_prctl, %rax
mov $ARCH_SET_FS, %rdi
mov (saved value), %rsi
syscall
ret

Yeah, it's ugly.  It may very well be worth changing this once the
FSBASE stuff happens.

--Andy