linux-kernel - Re: [PATCH] MIPS: Limit check_bugs32() under CONFIG

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, 9 Apr 2020 17:15:27 +0100 (BST)
From:   "Maciej W. Rozycki" <macro@...ux-mips.org>
To:     Jiaxun Yang <jiaxun.yang@...goat.com>
cc:     YunQiang Su <wzssyqa@...il.com>,
        Tiezhu Yang <yangtiezhu@...ngson.cn>,
        Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        linux-mips <linux-mips@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Xuefeng Li <lixuefeng@...ngson.cn>
Subject: Re: [PATCH] MIPS: Limit check_bugs32() under CONFIG_32BIT

On Thu, 9 Apr 2020, Jiaxun Yang wrote:

> > Why is using Kconfig supposed to be better?  Several configurations 
> >support multiple processor types (e.g. swappable CPU daugthercards or
> >FPGA 
> >soft-cores) and having to list CPU types across platforms as CPUs are 
> >added is going to be a maintenance nightmare.  Whereas having
> >workarounds 
> >or panics associated with run-time determination of the actual CPU type
> >
> >guarantees they will trigger where necessary.  The use of `init'
> >sections 
> >assures the reclaim of memory for use after bootstrap.
> 
> Actually I meant let bug checks depends on Kconfig's CPU selection.
> 
> It's guaranteed that you can only select one kind of CPU one time,
> to prevent the overhead of checking bugs on irrelevant processors.

 That makes no sense to me sorry.  When you select say a MIPS32r2 CPU for 
a Malta configuration, you can run it with a 4KE, 24K, 24KE, 34K, 74K, 
1004K, M14K, and probably a few other CPUs I have forgotten about.  Are 
you suggesting now that you want to require a separate kernel 
configuration for each of these CPUs?

> And we still have to check PRID/CPUTYPE during boot to enable
> proper workarounds, because the Kconfig options are telling about the possibility,
> which means a processor potentially has some kinds of bug.
> 
> In this case, M34K's errata should depends on or selected by 
> CPU_MIPS32_R2 in Kconfig.
> 
> So there won't be any nightmare, but only reduced code :-)

 You'll need to manually maintain CPU assignment to configurations, which 
is not needed now.

 Anyway, please show your patch to let us see any improvement brought by 
it and we can discuss it then.

  Maciej