linux-kernel - Re: [patch 0/8] x86/fpu: Mop up XSAVES and related damage

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:   Fri, 4 Jun 2021 10:46:24 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Thomas Gleixner <tglx@...utronix.de>,
        "Yu, Yu-cheng" <yu-cheng.yu@...el.com>,
        LKML <linux-kernel@...r.kernel.org>
Cc:     x86@...nel.org, Andy Lutomirski <luto@...nel.org>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Fenghua Yu <fenghua.yu@...el.com>,
        Tony Luck <tony.luck@...el.com>
Subject: Re: [patch 0/8] x86/fpu: Mop up XSAVES and related damage

On 6/4/21 7:05 AM, Thomas Gleixner wrote:
> But looking at the above, it's not clear to me why that PKRU stuff works
> at all (upstream), but I'll figure it out eventually. I'm quite sure
> that it does work by pure chance not by design.

The upstream flush_thread() code appears correct and even intentionally
so.  Just how we must eagerly load PKRU on a context switch, the
fpu__clear*() code eagerly "clears" PKRU.  It doesn't actually zero it,
of course, but reverts the register and the fpstate back to the
'init_pkru_value':

flush_thread()->fpu__clear_all()->fpu__clear(user_only=false)
	copy_init_fpstate_to_fpregs()
		copy_kernel_to_xregs(init_fpu) // fpstate
		copy_init_pkru_to_fpregs()
			 write_pkru(init_pkru_value_snapshot) // fpregs

Andy said you have a fix for this, but I think the new fpu__clear_all()
is failing to do the eager write_pkru().