[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1473887291-18384-1-git-send-email-khuey@kylehuey.com>
Date: Wed, 14 Sep 2016 14:08:08 -0700
From: Kyle Huey <me@...ehuey.com>
To: Robert O'Callahan <robert@...llahan.org>
Cc: linux-kernel@...r.kernel.org, Borislav Petkov <bp@...e.de>,
Andy Lutomirski <luto@...nel.org>
Subject: [RESEND][PATCH v2] arch_prctl,x86 Add ARCH_[GET|SET]_CPUID for controlling the CPUID instruction
(Resending because I screwed up the cover email, sorry about that.)
rr (http://rr-project.org/), a userspace record-and-replay reverse-
execution debugger, would like to trap and emulate the CPUID instruction.
This would allow us to a) mask away certain hardware features that rr does
not support (e.g. RDRAND) and b) enable trace portability across machines
by providing constant results.
4 patches follow, the first 3 to the kernel, and the final patch to man-pages.
The following changes have been made since v1:
Suggested by Borislav Petkov:
- Uses arch_prctl instead of prctl.
- Uses rdmsr_safe.
- Added sample man-pages patch.
- Various functions are renamed, style fixes.
Suggested by Andy Lutomirski:
- Added a cpufeature bit to show up in /proc/cpuinfo.
- Added sane behavior in Xen, by masking away the MSR_PLATFORM_INFO bit
showing support for this feature for now.
- Added a selftest, clarifying the bit is preserved on fork/exec.
The following issues were raised and are not addressed:
Use of cpuid within interrupt handlers: as Linus pointed out, CPUID only
faults at cpl>0, so this is not a concern.
Use a static_key instead of a TIF: I don't believe this solves anything.
There are currently 8 free TIF bits (after this patch), and it's always
possible to move this (or others) later if they are needed. Even if we were
to use a static_key we would still need to maintain state about which tasks
are subject to CPUID faulting and which are not somewhere else.
Powered by blists - more mailing lists