linux-kernel - Re: [PATCH 11/12] riscv: don't use global static vars to store alternative data

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:   Mon, 16 May 2022 08:15:41 +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 11/12] riscv: don't use global static vars to store
 alternative data

On Wed, May 11, 2022 at 09:29:20PM +0200, Heiko Stuebner wrote:
> Right now the code uses a global struct to store vendor-ids
> and another global variable to store the vendor-patch-function.
> 
> There exist specific cases where we'll need to patch the kernel
> at an even earlier stage, where trying to write to a static
> variable might actually result in hangs.
> 
> Also collecting the vendor-information consists of 3 sbi-ecalls
> (or csr-reads) which is pretty negligible in the context of
> booting a kernel.
> 
> So rework the code to not rely on static variables and instead
> collect the vendor-information when a round of alternatives is
> to be applied.
> 
> Signed-off-by: Heiko Stuebner <heiko@...ech.de>
> Reviewed-by: Guo Ren <guoren@...nel.org>
> Reviewed-by: Philipp Tomsich <philipp.tomsich@...ll.eu>
> ---
>  arch/riscv/kernel/alternative.c | 51 ++++++++++++++++-----------------
>  1 file changed, 24 insertions(+), 27 deletions(-)
> 
> diff --git a/arch/riscv/kernel/alternative.c b/arch/riscv/kernel/alternative.c
> index e6c9de9f9ba6..27f722ae452b 100644
> --- a/arch/riscv/kernel/alternative.c
> +++ b/arch/riscv/kernel/alternative.c
> @@ -16,41 +16,35 @@
>  #include <asm/sbi.h>
>  #include <asm/csr.h>
>  
> -static struct cpu_manufacturer_info_t {
> +struct cpu_manufacturer_info_t {
>  	unsigned long vendor_id;
>  	unsigned long arch_id;
>  	unsigned long imp_id;
> -} cpu_mfr_info;
> +	void (*vendor_patch_func)(struct alt_entry *begin, struct alt_entry *end,
> +				  unsigned long archid, unsigned long impid,
> +				  unsigned int stage);

Please drop the confusing vendor_ prefix for the function pointer
while you're at it.  The vendor id is just one of three inputs for
the patching.

Otherwise this looks good:

Reviewed-by: Christoph Hellwig <hch@....de>