linux-kernel - Re: [PATCH 6/8] MIPS: Limit MIPS_MT

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]

Message-ID: <alpine.DEB.2.21.2405162315290.32322@angie.orcam.me.uk>
Date: Thu, 16 May 2024 23:44:55 +0100 (BST)
From: "Maciej W. Rozycki" <macro@...am.me.uk>
To: Jiaxun Yang <jiaxun.yang@...goat.com>
cc: Thomas Bogendoerfer <tsbogend@...ha.franken.de>, 
    Nathan Chancellor <nathan@...nel.org>, 
    Nick Desaulniers <ndesaulniers@...gle.com>, 
    Bill Wendling <morbo@...gle.com>, Justin Stitt <justinstitt@...gle.com>, 
    "linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>, 
    linux-kernel@...r.kernel.org, llvm@...ts.linux.dev, 
    Guenter Roeck <linux@...ck-us.net>
Subject: Re: [PATCH 6/8] MIPS: Limit MIPS_MT_SMP support by ISA reversion

On Wed, 15 May 2024, Jiaxun Yang wrote:

> >> There is nothing stopping us to run R1 kernel on R2 hardware, given that
> >> those features are all detected at boot time. I understand MT was introduced
> >> at 34K which is R2.
> >
> >  We can certainly choose to support R2 features at run time with R1 kernel 
> > configurations, but it's not what the change description says (left quoted 
> > above for reference).  And the MT ASE, indeed first implemented with the 
> > 34K (for which I was a member of the product development team back at MIPS 
> > UK), is not a part of the R1 ISA specification set.
> >
> Good to know!
> 
> The motivation behind this patch is to workaround some randconfig failures
> that combines MT with early ISA release.

 I'd say it's an actual fix rather than just a workaround.

 Originally intention was with the MIPS port that eventually we would 
support a generic kernel configuration, such as original x86 Linux has 
always had or the Alpha port has at one point gained, where you can have 
respectively an i486 (or previously even i386) or EV4 CPU kernel binary 
that runs everywhere, even on the most recent hardware available.

 With the MIPS platform fragmentation it has proved too much of an effort
for the engineering resources we've had available and consequently never 
happened.  This is why we have retained numerous abstractions intended to 
switch between handlers at boot time (and had even more in the past).

 From R1 onwards the privileged architecture has become more uniform and
therefore easier to handle between ISA revisions and/or implementations 
and the choice of the CPU to build for has become more of a balance 
between backwards compatibility and optimisation stemming from a richer 
architecture and FWIW I fully support striving to make an R1 kernel binary 
run with any R1-R5 hardware.  It can be especially useful with platforms 
that have swappable CPU modules available at different ISA levels.

> They are not trivial to fix, so I just ban them in Kconfig. I was a little bit
> reluctant to admit that in commit message.

 Please always state your genuine motivation in change descriptions.  It 
lets reviewers understand what a change is about and if there is any 
concern about the description itself, then it can always be adjusted in 
the review if needed.

  Maciej