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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Thu, 13 Aug 2015 09:09:49 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Stas Sergeev <stsp@...t.ru>
Cc:	Ingo Molnar <mingo@...nel.org>, X86 ML <x86@...nel.org>,
	Linux kernel <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Brian Gerst <brgerst@...il.com>,
	Borislav Petkov <bp@...en8.de>,
	Stas Sergeev <stsp@...rs.sourceforge.net>
Subject: Re: [regression] x86/signal/64: Fix SS handling for signals delivered
 to 64-bit programs breaks dosemu

On Thu, Aug 13, 2015 at 9:03 AM, Stas Sergeev <stsp@...t.ru> wrote:
> 13.08.2015 18:38, Andy Lutomirski пишет:
>>
>>
>> So...  what do we do about it?  We could revert the whole mess.  We
>> could tell everyone to fix their DOSEMU, which violates policy and is
>> especially annoying given how much effort we've put into keeping
>> 16-bit mode fully functional lately.  We could add yet more heuristics
>> and teach sigreturn to ignore the saved SS value in sigcontext if the
>> saved CS is 64-bit and the saved SS is unusable.
>
> Andy, why do you constantly ignore the proposal to make
> new behaviour explicitly controlable? You don't have to agree
> with it, but you could at least comment on that possibility
> and/or mention it with the ones you listed above.

I'm not sure what the proposal is exactly.

We could add a new uc_flags flag.  If set, it means that
sigcontext->ss is valid and should be used by sigreturn.  If clear,
then we ignore sigcontext->ss and just restore __USER_DS.

The problem is that, by itself, this won't fix old DOSEMU.  We somehow
need to either detect that something funny is going on or just leave
the flag clear by default.

We could do this: always save SS to sigcontext->ss, but only restore
sigcontext->ss if userspace explicitly sets the flag before sigreturn.
If we do that, we'd need to also add my patch to preserve the actual
HW SS selector if possible so that old DOSEMU knows what SS to program
into its trampoline.

This at least lets *new* DOSEMU set the flag and get the improved
behavior.  I still don't know what effect it'll have on Wine and CRIU.

Stas, is that what you were thinking, or were you thinking of something else?

--Andy
--
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/