linux-kernel - Re: objective rules for architecture removal

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] [day] [month] [year] [list]

Date:   Thu, 18 May 2017 11:39:34 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Waldemar Brodkorb <wbx@...nadk.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Hans-Christian Noren Egtvedt <egtvedt@...fundet.no>
Subject: Re: objective rules for architecture removal

On Thu, May 18, 2017 at 7:45 AM, Waldemar Brodkorb <wbx@...nadk.org> wrote:
>
> are there any objective rules for removal of architecture support from
> the Linux kernel tree?

Objective rules for that in particular? No.

We do have the whole "no regressions" rule, which covers pretty much
anything except for bad security issues that can't be fixed any other
way (and then we really do try to find alternatives that fix the
problem without breaking whatever application depends on bad
interfaces).

But even with regressions, it's also an issue of "if there's only one
or two technically savvy users" and they can fix the regression
outside of kernel work. That comes up if we have some odd kernel
command line thing that some kernel developer used - we just tell him
to use a new command line instead.

So even that "no regressions" rule isn't _entirely_ black-and-white,
although it's about as close to a hard objective rule we have in
kernel development.

> I always loved that Linux kernel does support many architectures and keep supporting
> all of them. Any chance to rethink about the removal?

So what I think would need to happen is:

 - somebody who maintains it and is motivated

 - minimizing the cost of maintenance to everybody else

 - re-introduce the architecture not as a revert, but as a
re-instatement of the minimal possible support that is actually used
by people.

There is an existing example of this: the H8/300 architecture
(arch/h8300) was removed in Nov 2013, and then re-introduced in June
2015 in a cleaned-up form:

 - removal commit: 55a7d4b85ca1

    195 files changed, 9 insertions(+), 11743 deletions(-)

 - added back in: 4b4d2b463461

    123 files changed, 7597 insertions(+), 28 deletions(-)

And you can see how the re-introduction was noticeably smaller than
the original removal.

And in fact, that "re-introduced in a cleaned-up form" as opposed to
just reverting the removal is fairly critical for me for a
meta-reason: it shows that whoever wants to resurrect the architecture
is serious about it and willing to put in some effort into it.

So there is absolutely no reason it can't be resurrected, but it does
require some work on the part of whoever wants to do so.

                  Linus