linux-kernel - Re: [RFC PATCH, x86]: Disable CPA cache flush for selfsnoop targets

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, 15 Jul 2019 20:41:01 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Andi Kleen <ak@...ux.intel.com>
cc:     Uros Bizjak <ubizjak@...il.com>, linux-kernel@...r.kernel.org,
        x86@...nel.org, Andrew Lutomirski <luto@...nel.org>
Subject: Re: [RFC PATCH, x86]: Disable CPA cache flush for selfsnoop
 targets

On Mon, 15 Jul 2019, Andi Kleen wrote:
> Uros Bizjak <ubizjak@...il.com> writes:
> 
> > Recent patch [1] disabled a self-snoop feature on a list of processor
> > models with a known errata, so we are confident that the feature
> > should work on remaining models also for other purposes than to speed
> > up MTRR programming.
> 
> MTRR is very different than TLBs.
> 
> >From my understanding not flushing with PAT is only safe everywhere when
> the memory is only used for coherent devices (like the Internal GPU on
> Intel CPUs). We don't have any infrastructure to track or enforce
> this unfortunately.

Right, we don't know where the PAT invocation comes from and whether they
are safe to omit flushing the cache. The module load code would be one
obvious candidate.

But unless there is some really worthwhile speedup, e.g. for boot, then
adding some flag to let CPA know about the safe 'no flush' operation might
be not worth it.

Thanks,

	tglx