linux-kernel - [PATCH 0/5] x86/pkeys: PKRU manipulation bug fixes and cleanups

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 27 May 2021 16:51:09 -0700
From:   Dave Hansen <dave.hansen@...ux.intel.com>
To:     linux-mm@...ck.org
Cc:     linux-kernel@...r.kernel.org,
        Dave Hansen <dave.hansen@...ux.intel.com>, tglx@...utronix.de,
        mingo@...hat.com, bp@...en8.de, x86@...nel.org, luto@...nel.org,
        shuah@...nel.org, babu.moger@....com, dave.kleikamp@...cle.com,
        linuxram@...ibm.com, bauerman@...ux.ibm.com
Subject: [PATCH 0/5] x86/pkeys: PKRU manipulation bug fixes and cleanups

Andy Lutomirski recently noted a probable bug in write_pkru(), but
it was unclear if it was user-visible.  A recent bug report in
related code[1] forced me to take a look.

Basically, manipulation of XSAVE state is too unstructured.
get_xsave_addr() gives callers the impression they can read and
write XSAVE state when there are a lot of pitfalls, like updates
to xstate.features bits.

As a result, more than one call site screws up the modification
of PKRU in the XSAVE buffer.  This series fixes that problem up
and also hopefully carves out a less error-prone path that can
be reused for other XSAVE features.

This series:
 * Moves the PKRU manipulation to a more appropriate location,
   away from the page table code
 * Wraps get_xsave_addr() with more structured, less error-prone
   interfaces.
 * Conditionally hides a pkey debugfs file, eliminating the need
   for new runtime checks to work with the new interface.
 * Add a selftest to make it more likely to catch bugs like this
   in the future.  This improved selftest catches this issue on
   Intel CPUs.  Without the improvement, it only triggers on AMD.

This has been lightly tested so far.  It probably needs a
tested-by from at least the AMD folks before anyone applies it.

1. https://lore.kernel.org/linux-kselftest/b2e0324a-9125-bb34-9e76-81817df27c48@amd.com/

--

 arch/x86/include/asm/fpu/internal.h          |    8 -
 arch/x86/include/asm/fpu/xstate.h            |  130 +++++++++++++++++++++++++++
 arch/x86/include/asm/pgtable.h               |   29 ------
 arch/x86/include/asm/processor.h             |    7 +
 arch/x86/kernel/cpu/common.c                 |    6 -
 arch/x86/kernel/fpu/xstate.c                 |    2 
 arch/x86/kernel/process_64.c                 |    1 
 arch/x86/kvm/svm/sev.c                       |    1 
 arch/x86/kvm/x86.c                           |    1 
 arch/x86/mm/pkeys.c                          |   13 +-
 tools/testing/selftests/vm/Makefile          |    4 
 tools/testing/selftests/vm/pkey-x86.h        |    1 
 tools/testing/selftests/vm/protection_keys.c |   73 +++++++++++++++
 13 files changed, 227 insertions(+), 49 deletions(-)

Cc: Thomas Gleixner <tglx@...utronix.de>
Cc: Ingo Molnar <mingo@...hat.com>
Cc: Borislav Petkov <bp@...en8.de>
Cc: x86@...nel.org
Cc: Andy Lutomirski <luto@...nel.org>
Cc: Shuah Khan <shuah@...nel.org>
Cc: Babu Moger <babu.moger@....com>
Cc: Dave Kleikamp <dave.kleikamp@...cle.com>
Cc: Ram Pai <linuxram@...ibm.com>
Cc: Thiago Jung Bauermann <bauerman@...ux.ibm.com>