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: <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

Powered by Openwall GNU/*/Linux Powered by OpenVZ