linux-kernel - [PATCH RFC 0/3] x86/fpu: defer FPU state loading until return to userspace

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-next>] [day] [month] [year] [list]

Message-Id: <1476734984-13839-1-git-send-email-riel@redhat.com>
Date:   Mon, 17 Oct 2016 16:09:41 -0400
From:   riel@...hat.com
To:     linux-kernel@...r.kernel.org
Cc:     mingo@...nel.org, bp@...en8.de, torvalds@...ux-foundation.org,
        luto@...nel.org, dave.hansen@...el.linux.com, tglx@...utronix.de,
        hpa@...or.com
Subject: [PATCH RFC 0/3] x86/fpu: defer FPU state loading until return to userspace

These patches defer FPU state loading until return to userspace.

This has the advantage of not clobbering the FPU state of one task
with that of another, when that other task only stays in kernel mode.

It also allows us to skip the FPU restore in kernel_fpu_end(), which
will help tasks that do multiple invokations of kernel_fpu_begin/end
without returning to userspace, for example KVM VCPU tasks.

We could also skip the restore of the KVM VCPU guest FPU state at
guest entry time, if it is still valid, but I have not implemented
that yet.

The code that loads FPU context directly into registers from user
space memory, or saves directly to user space memory, is wrapped
in a retry loop, that ensures the FPU state is correctly set up
at the start, and verifies that it is still valid at the end.

I have stress tested these patches with various FPU test programs,
and things seem to survive.

However, I have not found any good test suites that mix FPU
use and signal handlers. Close scrutiny of these patches would
be appreciated.