linux-kernel - Re: [PATCH v8 01/14] riscv: prevent null-pointer dereference with sbi_remote_fence

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]

Message-ID: <20220331123322.GA26378@lst.de>
Date:   Thu, 31 Mar 2022 14:33:22 +0200
From:   Christoph Hellwig <hch@....de>
To:     Heiko Stübner <heiko@...ech.de>
Cc:     Christoph Hellwig <hch@....de>, 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,
        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, Atish Patra <atishp@...osinc.com>
Subject: Re: [PATCH v8 01/14] riscv: prevent null-pointer dereference with
 sbi_remote_fence_i

On Thu, Mar 31, 2022 at 02:28:06PM +0200, Heiko Stübner wrote:
> so essentially flushes the _local_ icache first and then tries to flush
> caches on other cores, either via an ipi or via sbi.
> 
> The remote-fence callback is set correctly during sbi_init().
> The other cores are only brought up after sbi-init is done.
> 
> So it's not really about error reporting but making sure that flush_icache_all()
> does something sane even when still running on the first core.
> As I assume the "all" means on all available cores (which would be the
> core the system booted on).
> 
> Does this make it clearer what this tries to solve?

A little.  Whatever code calls this early still seems broken to me
and just just do a local flush, though.