public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [RFC PATCH 0/2] uaccess: Add mechanism for key checked access to user memory
@ 2022-01-26 17:33 Janis Schoetterl-Glausch
  2022-01-26 17:33 ` [RFC PATCH 1/2] " Janis Schoetterl-Glausch
                   ` (3 more replies)
  0 siblings, 4 replies; 8+ messages in thread
From: Janis Schoetterl-Glausch @ 2022-01-26 17:33 UTC (permalink / raw)
  To: Arnd Bergmann, Andrew Morton, Heiko Carstens
  Cc: Janis Schoetterl-Glausch, Alexander Viro, Kees Cook,
	Christian Borntraeger, linux-kernel

Something like this patch series is required as part of KVM supporting
storage keys on s390.
See https://lore.kernel.org/kvm/20220118095210.1651483-1-scgl@linux.ibm.com/

On s390 each physical page is associated with 4 access control bits.
On access, these are compared with an access key, which is either
provided by the instruction or taken from the CPU state.
Based on that comparison, the access either succeeds or is prevented.

KVM on s390 needs to be able emulate this behavior, for example during
instruction emulation, when it makes accesses on behalf of the guest.
In order to do that, we need variants of __copy_from/to_user that pass
along an access key to the architecture specific implementation of
__copy_from/to_user. That is the only difference, variants do the same
might_fault(), instrument_copy_to_user(), etc. calls as the normal
functions do and need to be kept in sync with those.
If these __copy_from/to_user_key functions were to be maintained
in architecture specific code they would be prone to going out of sync
with their non key counterparts if there were code changes.
So, instead, add these variants to include/linux/uaccess.h.

Considerations:
 * The key argument is an unsigned long, in order to make the functions
   less specific to s390, which would only need an u8.
   This could also be generalized further, i.e. by having the type be
   defined by the architecture, with the default being a struct without
   any members.
   Also the functions could be renamed ..._opaque, ..._arg, or similar.
 * Which functions do we provide _key variants for? Just defining
   __copy_from/to_user_key would make it rather specific to our use
   case.
 * Should ...copy_from/to_user_key functions be callable from common
   code? The patch defines the functions to be functionally identical
   to the normal functions if the architecture does not define
   raw_copy_from/to_user_key, so that this would be possible, however it
   is not required for our use case.

For the minimal functionality we require see the diff below.

bloat-o-meter reported a .03% kernel size increase.

Comments are much appreciated.

Janis Schoetterl-Glausch (2):
  uaccess: Add mechanism for key checked access to user memory
  s390/uaccess: Provide raw_copy_from/to_user_key

 arch/s390/include/asm/uaccess.h |  22 ++++++-
 arch/s390/lib/uaccess.c         |  48 ++++++++------
 include/linux/uaccess.h         | 107 ++++++++++++++++++++++++++++++++
 lib/usercopy.c                  |  33 ++++++++++
 4 files changed, 188 insertions(+), 22 deletions(-)


diff --git a/include/linux/uaccess.h b/include/linux/uaccess.h
index ac0394087f7d..b3c58b7605d6 100644
--- a/include/linux/uaccess.h
+++ b/include/linux/uaccess.h
@@ -114,6 +114,20 @@ __copy_from_user(void *to, const void __user *from, unsigned long n)
 	return raw_copy_from_user(to, from, n);
 }
 
+#ifdef raw_copy_from_user_key
+static __always_inline __must_check unsigned long
+__copy_from_user_key(void *to, const void __user *from, unsigned long n,
+			  unsigned long key)
+{
+	might_fault();
+	if (should_fail_usercopy())
+		return n;
+	instrument_copy_from_user(to, from, n);
+	check_object_size(to, n, false);
+	return raw_copy_from_user_key(to, from, n, key);
+}
+#endif /* raw_copy_from_user_key */
+
 /**
  * __copy_to_user_inatomic: - Copy a block of data into user space, with less checking.
  * @to:   Destination address, in user space.
@@ -148,6 +162,20 @@ __copy_to_user(void __user *to, const void *from, unsigned long n)
 	return raw_copy_to_user(to, from, n);
 }
 
+#ifdef raw_copy_to_user_key
+static __always_inline __must_check unsigned long
+__copy_to_user_key(void __user *to, const void *from, unsigned long n,
+			unsigned long key)
+{
+	might_fault();
+	if (should_fail_usercopy())
+		return n;
+	instrument_copy_to_user(to, from, n);
+	check_object_size(from, n, true);
+	return raw_copy_to_user_key(to, from, n, key);
+}
+#endif /* raw_copy_to_user_key */
+
 #ifdef INLINE_COPY_FROM_USER
 static inline __must_check unsigned long
 _copy_from_user(void *to, const void __user *from, unsigned long n)

base-commit: 0280e3c58f92b2fe0e8fbbdf8d386449168de4a8
-- 
2.32.0


^ permalink raw reply related	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2022-02-03 19:20 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-01-26 17:33 [RFC PATCH 0/2] uaccess: Add mechanism for key checked access to user memory Janis Schoetterl-Glausch
2022-01-26 17:33 ` [RFC PATCH 1/2] " Janis Schoetterl-Glausch
2022-01-26 17:33 ` [RFC PATCH 2/2] s390/uaccess: Provide raw_copy_from/to_user_key Janis Schoetterl-Glausch
2022-01-31 13:39 ` [RFC PATCH 0/2] uaccess: Add mechanism for key checked access to user memory Christian Borntraeger
2022-02-03 18:11 ` Janis Schoetterl-Glausch
2022-02-03 18:11   ` [RFC PATCH 1/2] uaccess: Add mechanism for arch specific user access with argument Janis Schoetterl-Glausch
2022-02-03 19:20     ` Heiko Carstens
2022-02-03 18:11   ` [RFC PATCH 2/2] s390/uaccess: Provide raw_copy_from/to_user_opaque Janis Schoetterl-Glausch

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox