linux-kernel - Re: [PATCH v8 02/14] riscv: integrate alternatives better into the main architecture

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20220331095336.GB23422@lst.de>
Date:   Thu, 31 Mar 2022 11:53:36 +0200
From:   Christoph Hellwig <hch@....de>
To:     Heiko Stuebner <heiko@...ech.de>
Cc:     palmer@...belt.com, paul.walmsley@...ive.com,
        aou@...s.berkeley.edu, linux-riscv@...ts.infradead.org,
        linux-kernel@...r.kernel.org, wefu@...hat.com,
        liush@...winnertech.com, guoren@...nel.org, atishp@...shpatra.org,
        anup@...infault.org, drew@...gleboard.org, hch@....de,
        arnd@...db.de, wens@...e.org, maxime@...no.tech,
        gfavor@...tanamicro.com, andrea.mondelli@...wei.com,
        behrensj@....edu, xinhaoqu@...wei.com, mick@....forth.gr,
        allen.baum@...erantotech.com, jscheid@...tanamicro.com,
        rtrauben@...il.com, samuel@...lland.org, cmuellner@...ux.com,
        philipp.tomsich@...ll.eu
Subject: Re: [PATCH v8 02/14] riscv: integrate alternatives better into the
 main architecture

On Thu, Mar 24, 2022 at 01:06:58AM +0100, Heiko Stuebner wrote:
> Right now the alternatives need to be explicitly enabled and
> erratas are limited to SiFive ones.
> 
> Over time with more SoCs and additional RiscV extensions, many more
> erratas or other patch-worthy features will emerge, so it doesn't
> really make sense to have the core alternatives able to get
> deactivated.
> 
> So make it part of the core RiscV kernel and drop the main
> RISCV_ERRATA_ALTERNATIVES config symbol.
> 
> This mimics how other architectures like for example arm64 handle
> their alternatives implementation.

For minimal kernels like the k210 it would be really good to be
able to avoid any not strictly neeed code.  So I'd much rather
have the alternatives mechanism only built when it actually is needed,
not (semi-)unconditional.