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:	Fri, 14 Aug 2015 02:43:51 +0300
From:	Stas Sergeev <stsp@...t.ru>
To:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Raymond Jennings <shentino@...il.com>
Cc:	Cyrill Gorcunov <gorcunov@...il.com>,
	Andy Lutomirski <luto@...capital.net>,
	Pavel Emelyanov <xemul@...allels.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

14.08.2015 02:18, Linus Torvalds пишет:
> On Thu, Aug 13, 2015 at 4:05 PM, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
>> The _only_ thing that matters is that something broke.
> To clarify: things like test programs etc don't matter. Real
> applications, used by real users. That's what regressions cover. If
> you have a workflow that isn't just some random kernel test thing, and
> you depend on it, and we break it, the kernel is supposed to fix it.
>
> There are some (very few) exceptions.
>
> If it's a security issue, we may not be able to "fix" it, because
> other concerns can obviously take precedence.
>
> Also, sometimes the reports come in way too late - if you were running
> some stable distro kernel for several years, and updated, and notice a
> change that happened four years ago and modern applications now rely
> on the _new_ behavior, we may not be able to fix the regression any
> more.
>
> But no, "it was an unintentional kernel bug and clearly just stupid
> crap code, and we fixed it and now the kernel is much better and
> cleaner" is not a valid reason for regressions. We'll go back to the
> stupid and crap code if necessary, however much that may annoy us.
IMHO at least such ocasions should be listed somewhere,
and the software authors should be asked to fix their code.
Then you'll be able to re-visit the problem later.
It may be unreasonable to carry the compatibility hacks forever
if the software that needed it, released the fix 10 years ago.

In fact, in the cases I can remember, the kernel patches
were never reverted, see this for instance:
https://lkml.org/lkml/2005/3/26/21
And there were many other breakages too, for example when
kernel started to use top-down memory allocations. These
were because of the poor code in dosemu, and dosemu was
asked to fix the code. I guess the policy to never break userspace
was not existing back then. Or there is some margin below
which the code quality is considered not worth the troubles. :)
--
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/