linux-kernel - Re: [PATCH] x86/fpu: Don't cache access to fpu_fpregs_owner

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:   Wed, 27 Nov 2019 13:42:47 -0500
From:   Barret Rhoden <brho@...gle.com>
To:     Borislav Petkov <bp@...en8.de>,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc:     Josh Bleecher Snyder <josharian@...il.com>,
        "Rik van Riel\"" <riel@...riel.com>, x86@...nel.org,
        linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, ian@...s.com
Subject: Re: [PATCH] x86/fpu: Don't cache access to fpu_fpregs_owner_ctx

>> Use this_cpu_read() instead this_cpu_read_stable() to avoid caching of
>> fpu_fpregs_owner_ctx during preemption points.
>>
>> Fixes: 5f409e20b7945 ("x86/fpu: Defer FPU state load until return to userspace")
> 
> Or
> 
> a352a3b7b792 ("x86/fpu: Prepare copy_fpstate_to_sigframe() for TIF_NEED_FPU_LOAD")
> 
> maybe, which adds the fpregs_unlock() ?

Using this_cpu_read_stable() (or some variant) seems to go back quite a 
while; not sure when exactly it became a problem.  If it helps, commit 
d9c9ce34ed5c ("x86/fpu: Fault-in user stack if 
copy_fpstate_to_sigframe() fails") was the one that popped up the most 
during Austin's bisection.

>> Also I would like to add
>> 	Debugged-by: Ian Lance Taylor
> 
> Yes, pls. CCed.

To close the loop on this, here's what Austin wrote on the bugzilla:

> --- Comment #2 from Austin Clements (austin@...gle.com) ---
> I can confirm that the patch posted by Sebastian Andrzej Siewior at
> https://lkml.org/lkml/2019/11/27/304 fixes the issue both in our C reproducer
> and in our original Go reproducer. (Sorry, I'm not subscribed to LKML, so I
> can't reply there, and I'm on an airplane, so it's hard to get subscribed :)
> 
> Regarding the question about the "Debugged-by" line in the patch, debugging was
> a joint effort between myself (Austin Clements <austin@...gle.com>), David
> Chase <drchase@...ang.org>, and Ian Lance Taylor <ian@...s.com>.

Thanks,

Barret