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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 11 Aug 2015 17:38:07 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Stas Sergeev <stsp@...t.ru>, X86 ML <x86@...nel.org>
Cc:	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

On Tue, Aug 11, 2015 at 5:17 PM, Stas Sergeev <stsp@...t.ru> wrote:
> Hi guys, I wonder how easily the include/uapi/* is being
> changed these days.
> The patch:
> http://lkml.kernel.org/r/405594361340a2ec32f8e2b115c142df0e180d8e.1426193719.git.luto@kernel.org
> breaks dosemu (and perhaps everyone else who used
> to restore the segregs by hands). And the fix involves
> both autoconf magic and run-time magic, so it is not even
> trivial.
> 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.

I didn't anticipate any breakage.  I could have been wrong.

Do you know what the actual breakage is?  I'm curious how this ever
worked for DOSEMU, given that, before this patch, it appeared to be
impossible to return to any nonstandard SS from a 64-bit signal
handler.  FWIW, DOSEMU seems to work for me on recent kernels.

We might still be able to require a new sigcontext flag to be set and
to forcibly return to __USER_DS if the flag is set regardless of the
ss value in sigcontext when sigreturn is called, if that is indeed the
problem with DOSEMU.  But I'm not actually sure that that's the
problem.

In fact, DOSEMU contains this:

  /* set up a frame to get back to DPMI via iret. The kernel does not save
     %ss, and the SYSCALL instruction in sigreturn() destroys it.

     IRET pops off everything in 64-bit mode even if the privilege
     does not change which is nice, but clobbers the high 48 bits
     of rsp if the DPMI client uses a 16-bit stack which is not so
     nice (see EMUfailure.txt). Setting %rsp to 0x100000000 so that
     bits 16-31 are zero works around this problem, as DPMI code
     can't see bits 32-63 anyway.
 */

So, if DOSEMU were to realize that both sigreturnissues it's
complaining about are fixed in recent kernels, it could sigreturn
directly back to any state.  (It can't *directly* IRET back to a
16-bit state with properly controlled RSP, but it can do it via
sigreturn.)

I don't actually see any code in DOSEMU that generates a sigcontext
from scratch (as opposed to copying one and modifying it), so I'm not
entirely sure what the problem is.

--Andy

-- 
Andy Lutomirski
AMA Capital Management, LLC
--
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/