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]

Message-ID: <55CCEC6C.3000800@list.ru>
Date:	Thu, 13 Aug 2015 22:13:48 +0300
From:	Stas Sergeev <stsp@...t.ru>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	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

13.08.2015 22:01, Andy Lutomirski пишет:
> On Thu, Aug 13, 2015 at 11:57 AM, Stas Sergeev <stsp@...t.ru> wrote:
>> 13.08.2015 21:35, Linus Torvalds пишет:
>>> On Thu, Aug 13, 2015 at 10:51 AM, Stas Sergeev <stsp@...t.ru> wrote:
>>>> Hello Linus, I verified that patch-minimal.diff is enough
>>>> to fix the problem, BUT! dosemu is in fact using the .fs and
>>>> .gs fields of sigcontext as a placeholders. Why the minimal
>>>> patch alone helps is simply because the kernel headers
>>>> installed in a system do not yet represent the newer kernel
>>>> developments and have the .fs and .gs fields in.
>>> Ok. So I'm inclined to do the bigger revert, just to fix the compile
>>> issue. It would be crazy to force some silly autoconf script for
>>> random header info.
>> But OTOH these fields already lost their meaning.
>> It may make sense to force people to stop using them,
>> in case you ever want to re-use them again in the future.
>>  From what Andy says, it seems there are the distant plans
>> to start restoring FS again. If people still use sigcontext.fs
>> by that time, you'll get problems. If you force everyone to
>> stop using them - you'll be safe.
> There are distant plans to think about restoring them, at least.  But
> it's not just FS -- it's FSBASE as well, and that's not going to fit
> in the same slot.  And we still don't get to break old DOSEMU versions
> (knowingly, anyway).
>
>> In fact, I think the "silly autoconf script" you mentioned above,
>> should indeed be reverted, and instead I should use
>> sigcontext.reserved1[8] array to store FS/GS? Is this
>> safer against ever re-using this space? Not sure...
> Honestly, I'd just save it somewhere outside sigcontext.  If it's
> application data, treat it as such.  OTOH, if you've already been
> saving it in the old FS/GS slots, I see no great reason to change it.
OK, as you promise not to re-use the same slots in the future,
I won't change it. Thanks.
As for the compilation failure - I am surprised you even care.
I thought the "we don't break userspace" covers only run-time,
not compile-time. Oh well.
--
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/