mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Janis Schoetterl-Glausch <scgl@linux.ibm.com>
To: scgl@linux.ibm.com
Cc: akpm@linux-foundation.org, arnd@arndb.de,
	borntraeger@linux.ibm.com, hca@linux.ibm.com,
	keescook@chromium.org, linux-kernel@vger.kernel.org,
	viro@zeniv.linux.org.uk
Subject: Re: [RFC PATCH 0/2] uaccess: Add mechanism for key checked access to user memory
Date: Thu,  3 Feb 2022 19:11:39 +0100	[thread overview]
Message-ID: <20220203181141.2682997-1-scgl@linux.ibm.com> (raw)
In-Reply-To: <20220126173358.2951879-1-scgl@linux.ibm.com>

> 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.
> 
After thinking about it some more, this variant seems an attractive
compromise between the different dimensions.
It maximises extensibility by having the additional argument and
semantic completely architecture defined.
At the same time it keeps the changes to the minimum, which reduces the
maintenance cost of keeping the functions in sync.
It is also clear how other use cases can be supported, when they arise.
Calling the functions from common code would be supported by defining
the opaque argument as an empty struct by default, and defaulting to
raw_copy_from/to_user. If other variants of copy to/from user with an
additional argument are required they can be added in the same manner as
is done here for __copy_from/to_user.
> 
> Comments are much appreciated.

Janis Schoetterl-Glausch (2):
  uaccess: Add mechanism for arch specific user access with argument
  s390/uaccess: Provide raw_copy_from/to_user_opaque

 arch/s390/include/asm/uaccess.h | 27 ++++++++++++++--
 arch/s390/lib/uaccess.c         | 56 ++++++++++++++++++++-------------
 include/linux/uaccess.h         | 28 +++++++++++++++++
 3 files changed, 88 insertions(+), 23 deletions(-)

-- 
2.32.0


  parent reply	other threads:[~2022-02-03 18:12 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-26 17:33 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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220203181141.2682997-1-scgl@linux.ibm.com \
    --to=scgl@linux.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=borntraeger@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome