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: <CA+55aFxk8-BsiKwr_S-c+4G6wihKPQVMLE34H9wOZpeua6W9+Q@mail.gmail.com>
Date:	Thu, 13 Aug 2015 17:02:12 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Stas Sergeev <stsp@...t.ru>
Cc:	Raymond Jennings <shentino@...il.com>,
	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

On Thu, Aug 13, 2015 at 4:43 PM, Stas Sergeev <stsp@...t.ru> wrote:
> 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. :)

Back in 2005 we may well not have been as strict about regressions as
we are now, no. The strict policy of no regressions actually
originally started mainly wrt suspend/resume issues, where the "fix
one machine, break another" kind of back-and-forth caused endless
problems, and meant that we didn't actually necessarily make any
forward progress, just moving a problem around.

(That said, I'd like to think that we've _always_ tried very hard to
not break stuff, it just wasn't necessarily the kind of very explicit
and hard rule that it is these days).

Also, there are certainly developers who push back on fixing the
regressions they caused. That is in fact the cause of some of my more
memorable explosions. But if I'm not brought into the discussion, and
the push-back happens on a mailing list, I may not even be aware of
the regression and the fact that a developer isn't willing to fix it.

I've also seen other projects be more willing to work around problems
like this than I personally would consider to be a good idea. For
example, we had some Wine regressions that broke a steam game or two,
and it was debugged on the steam and wine lists, and took a longish
time to actually even get to the attention of kernel people, because
the developers were actually willing to try to do an update and fix
their application to not do the thing that caused problems. Which I
certainly appreciate, but at the same time that doesn't necessarily
help the user who sits there with a game that just didn't work. So
even if an app is getting updated eventually, the kernel breakage
should be fixed.

So if some patch causes problems, and the author of the patch doesn't
acknowledge the problem or even if the application developer says "we
can work around that", always feel free to escalate the issue and
bring in upper maintainers.

That said, it *does* depend a bit on just how core the area is.
Sometimes it just gets too painful to fix things, and while the "no
regressions" rule is pretty damn close to the strictest rule we have,
there are never any completely absolute rules. As mentioned, there are
exceptions to the regression rule too, and sometimes the result might
just end up being "very few people are actually affected, and there's
a sufficiently good reason for the regression that we'll just cop
out".

But that should really be a very rare occurrence. We used to have
quite a lot of those kinds of issues with the GPU layer (resulting in
flag-days with the X server etc), and it really causes huge problems.

So there are no absolutes. But regressions are a serious problem, and
need to be treated as such. I will not _guarantee_ that we always fix
them, but I would hope we do our best.

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