Message-ID: <55D455FA.20903@list.ru>
Date:	Wed, 19 Aug 2015 13:10:02 +0300
From:	Stas Sergeev <stsp@...t.ru>
To:	Andy Lutomirski <luto@...capital.net>
CC:	Brian Gerst <brgerst@...il.com>,
	Linux kernel <linux-kernel@...r.kernel.org>
Subject: Re: [regression] x86/signal/64: Fix SS handling for signals delivered
 to 64-bit programs breaks dosemu

19.08.2015 01:42, Andy Lutomirski пишет:
> On Mon, Aug 17, 2015 at 11:29 PM, Stas Sergeev <stsp@...t.ru> wrote:
>> 13.08.2015 20:00, Brian Gerst пишет:
>>
>>> On Thu, Aug 13, 2015 at 11:43 AM, Andy Lutomirski <luto@...capital.net>
>>> wrote:
>>>>
>>>> On Thu, Aug 13, 2015 at 8:37 AM, Linus Torvalds
>>>> <torvalds@...ux-foundation.org> wrote:
>>>>>
>>>>> On Tue, Aug 11, 2015 at 5:17 PM, Stas Sergeev <stsp@...t.ru> wrote:
>>>>>>
>>>>>> I realize this patch may be good to have in general, but
>>>>>> breaking userspace without a single warning is a bit
>>>>>> discouraging. Seems like the old "we don't break userspace"
>>>>>> rule have gone.
>>>>>
>>>>> That rule hasn't gone anywhere.
>>>>>
>>>>> Does a plain revert just fix everything? Because if so, that's the
>>>>> right thing to do, and we can just re-visit this later.
>>>>>
>>>>> I don't understand why Andy and Ingo are even discussing this. What
>>>>> the f*ck, guys?
>>>>>
>>>> I'm trying to fix it without reverting.  If that doesn't work, then we
>>>> revert.  Yesterday, I thought I had a reasonably clean fix, but it
>>>> turned out that it only solved half of the problem.
>>>>
>>>> If we revert, I think I need to check what will break due to the
>>>> revert.  I need to check at least Wine, and we'll have to do something
>>>> about all the selftests that will start failing.  I also need to check
>>>> CRIU, and IIRC CRIU has started using the new sigcontext SS in new
>>>> versions.
>>>
>>> I don't think Wine will be a problem, at least how it is currently set
>>> up.  16-bit support is only in the 32-bit build.  The 64-bit build
>>> only supports Win64 apps, and will call the 32-bit version (installed
>>> in parallel) to run 32 and 16-bit apps.
>>
>> Is this also because of the lack of the proper 32/16bit support in
>> a 64bit kernels? If so, dosemu's work-arounds do not look like the
>> too bad thing compared to that. :)
> 
> 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.

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!

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.

This is what I called a 32/16bit support, and in fact, when I installed
dosemu on a 64bit machine, started win31 and it just worked, I
immediately wrote my regards to Bart Oldeman, so much I was impressed -
I thought it is absolutely impossible to make this whole mess working
reliably.
I guess wine authors just were not as brave and decided to wait for
the kernel functionality in place.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists