Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751543AbbHSPfu (ORCPT ); Wed, 19 Aug 2015 11:35:50 -0400 Received: from mail-ob0-f171.google.com ([209.85.214.171]:33823 "EHLO mail-ob0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750921AbbHSPfs convert rfc822-to-8bit (ORCPT ); Wed, 19 Aug 2015 11:35:48 -0400 MIME-Version: 1.0 In-Reply-To: <55D455FA.20903@list.ru> References: <55CA90B4.2010205@list.ru> <55D2D0DE.3080707@list.ru> <55D455FA.20903@list.ru> From: Andy Lutomirski Date: Wed, 19 Aug 2015 08:35:28 -0700 Message-ID: Subject: Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu To: Stas Sergeev Cc: Brian Gerst , Linux kernel Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2751 Lines: 76 On Wed, Aug 19, 2015 at 3:10 AM, Stas Sergeev 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/