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 12:37:57 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Stas Sergeev <stsp@...t.ru>
Cc:	Andy Lutomirski <luto@...capital.net>,
	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 12:13 PM, Stas Sergeev <stsp@...t.ru> wrote:
>
> 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.

I definitely care.

Compile issues may be slightly lower on my radar, but the basic rule
should be that upgrading a kernel shouldn't cause problems.

The only exception is for stuff that gets very intimate with the
kernel itself - ie things like external modules etc. Those we don't
really try to cater to, or care about.

Things that actually include internal kernel headers tend to have just
themselves to blame and historically we really didn't care very much
(long long ago we had issues with ext3fs-tools etc until those kinds
of things just ended up making their own copies).

But the point of the uabi headers was that even _that_ is supposed to
actually work, at least for the limited case of those headers.. So if
a uabi header change causes problems, we really *should* care, because
otherwise, what was the point of that whole uabi rework, really?

(And no, we've not always succeeded in that "shouldn't cause problems"
space.  So I'm not claiming we have a perfect track record, but I do
claim that I at least care very deeply)

                   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/