linux-kernel - [RFC PATCH 0/6] User pkey minor bug fixes

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: <20220610233533.3649584-1-ira.weiny@intel.com>
Date:   Fri, 10 Jun 2022 16:35:27 -0700
From:   ira.weiny@...el.com
To:     linux-api@...r.kernel.org
Cc:     Ira Weiny <ira.weiny@...el.com>,
        Sohil Mehta <sohil.mehta@...el.com>, x86@...nel.org,
        linuxppc-dev@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org, linux-kselftest@...r.kernel.org
Subject: [RFC PATCH 0/6] User pkey minor bug fixes

From: Ira Weiny <ira.weiny@...el.com>

While evaluating the possibility of defining a new type for pkeys within the
kernel I found a couple of minor bugs.

Because these patches clean up the return codes from system calls I'm sending
this out RFC hoping that users will speak up if anything breaks.

I'm not too concerned about pkey_free() because it is unlikely that anyone is
checking the return code.  Interestingly enough, glibc recommends not calling
pkey_free() because it does not change the access rights to the key and may be
subsequently allocated again.[1][2]

The pkey_alloc() is more concerning.  However, I checked the Chrome source and
it does not differentiate among the return codes and maps all errors into
kNoMemoryProtectionKey.

glibc says it returns ENOSYS if the system does not support pkeys but I don't
see where ENOSYS is returned?  AFAICS it just returns what the kernel returns.
So it is probably up to user of glibc.

In addition I've enhanced the pkey tests to verify and test the changes.

Thanks to Rick Edgecombe and Sohil Mehta for internal review.

[1] Quote from manual/memory.texi:

Calling this function does not change the access rights of the freed
protection key.  The calling thread and other threads may retain access
to it, even if it is subsequently allocated again.  For this reason, it
is not recommended to call the @code{pkey_free} function.

[2] PKS had a similar issue and went to statically allocated keys instead.

Ira Weiny (6):
  testing/pkeys: Add command line options
  testing/pkeys: Don't use uninitialized variable
  testing/pkeys: Add additional test for pkey_alloc()
  pkeys: Lift pkey hardware check for pkey_alloc()
  pkeys: Up level pkey_free() checks
  pkeys: Change mm_pkey_free() to void

 arch/powerpc/include/asm/pkeys.h             | 18 ++---
 arch/x86/include/asm/pkeys.h                 |  7 +-
 include/linux/pkeys.h                        |  5 +-
 mm/mprotect.c                                | 13 +++-
 tools/testing/selftests/vm/pkey-helpers.h    |  7 +-
 tools/testing/selftests/vm/protection_keys.c | 75 +++++++++++++++++---
 6 files changed, 86 insertions(+), 39 deletions(-)

base-commit: 874c8ca1e60b2c564a48f7e7acc40d328d5c8733
-- 
2.35.1