Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
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
Message-Id: <20220203181141.2682997-1-scgl@linux.ibm.com>
In-Reply-To: <20220126173358.2951879-1-scgl@linux.ibm.com>
References: <20220126173358.2951879-1-scgl@linux.ibm.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk

> 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