From: Heiko Carstens <hca@linux.ibm.com>
To: Janis Schoetterl-Glausch <scgl@linux.ibm.com>
Cc: Vasily Gorbik <gor@linux.ibm.com>,
Christian Borntraeger <borntraeger@linux.ibm.com>,
Sven Schnelle <svens@linux.ibm.com>,
Nico Boehr <nrb@linux.ibm.com>,
Alexander Gordeev <agordeev@linux.ibm.com>,
linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v1 01/10] s390/uaccess: Add storage key checked access to user memory
Date: Wed, 19 Jan 2022 14:20:09 +0100 [thread overview]
Message-ID: <YegQCTqEsiFTUZ2R@osiris> (raw)
In-Reply-To: <422595a5-b24b-8760-ff0e-112322142de7@linux.ibm.com>
On Wed, Jan 19, 2022 at 12:02:34PM +0100, Janis Schoetterl-Glausch wrote:
> > That's a lot of code churn... I would have expected that the existing
> > functions will be renamed, get an additional key parameter, and the
> > current API is implemented by defines which map copy_to_user() &
> > friends to the new functions, and add a zero key.
>
> I don't think I understand you. I can implement raw_copy_from/to_user
> in terms of raw_copy_from/to_user_with_key, which does save a few lines,
> but that's it, isn't it?
Right you are. I only looked at your patch, and forgot about that all
the wrapping is nowadays done in common code.
So what I really don't like about this approach is that we get an arch
specific copy_to_user() implementation back. This means that all those
extra calls like might_fault(), instrument_copy_to_user(), and friends
now have to be kept in sync by us again, if new instrumentation or
security options are added to common code.
Given that this is manual work / monitoring I'm sure this will not
work in the mid or long term, like it has been proven several times in
the past for other features. We need something better, which works
out-of-the-box wrt common code changes / enhancements.
next prev parent reply other threads:[~2022-01-19 13:20 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-18 9:52 [RFC PATCH v1 00/10] KVM: s390: Do storage key checking Janis Schoetterl-Glausch
2022-01-18 9:52 ` [RFC PATCH v1 01/10] s390/uaccess: Add storage key checked access to user memory Janis Schoetterl-Glausch
2022-01-18 13:18 ` Janosch Frank
2022-01-18 15:37 ` Sven Schnelle
2022-01-18 15:52 ` Janis Schoetterl-Glausch
2022-01-19 9:48 ` Heiko Carstens
2022-01-19 11:02 ` Janis Schoetterl-Glausch
2022-01-19 13:20 ` Heiko Carstens [this message]
2022-01-20 8:34 ` Janis Schoetterl-Glausch
2022-01-20 12:56 ` Heiko Carstens
2022-01-20 18:19 ` Heiko Carstens
2022-01-21 7:32 ` Christian Borntraeger
2022-01-21 11:04 ` Heiko Carstens
2022-01-21 13:46 ` Janis Schoetterl-Glausch
2022-01-21 14:26 ` Heiko Carstens
2022-01-24 10:38 ` [RFC PATCH] uaccess: Add mechanism for " Janis Schoetterl-Glausch
2022-01-24 17:41 ` Heiko Carstens
2022-01-25 12:35 ` Janis Schoetterl-Glausch
2022-01-25 13:23 ` Heiko Carstens
2022-01-18 9:52 ` [RFC PATCH v1 02/10] KVM: s390: Honor storage keys when accessing guest memory Janis Schoetterl-Glausch
2022-01-18 14:38 ` Janosch Frank
2022-01-20 10:27 ` Christian Borntraeger
2022-01-20 10:30 ` Janis Schoetterl-Glausch
2022-01-19 19:27 ` Christian Borntraeger
2022-01-20 8:11 ` Janis Schoetterl-Glausch
2022-01-20 8:50 ` Christian Borntraeger
2022-01-20 8:58 ` Janis Schoetterl-Glausch
2022-01-20 9:06 ` Christian Borntraeger
2022-01-18 9:52 ` [RFC PATCH v1 03/10] KVM: s390: handle_tprot: Honor storage keys Janis Schoetterl-Glausch
2022-01-18 9:52 ` [RFC PATCH v1 04/10] KVM: s390: selftests: Test TEST PROTECTION emulation Janis Schoetterl-Glausch
2022-01-20 15:40 ` Janosch Frank
2022-01-21 11:03 ` Janis Schoetterl-Glausch
2022-01-21 12:28 ` Claudio Imbrenda
2022-01-21 13:50 ` Janis Schoetterl-Glausch
2022-01-18 9:52 ` [RFC PATCH v1 05/10] KVM: s390: Add optional storage key checking to MEMOP IOCTL Janis Schoetterl-Glausch
2022-01-18 11:51 ` Christian Borntraeger
2022-01-18 9:52 ` [RFC PATCH v1 06/10] KVM: s390: Add vm IOCTL for key checked guest absolute memory access Janis Schoetterl-Glausch
2022-01-19 11:52 ` Thomas Huth
2022-01-19 12:46 ` Christian Borntraeger
2022-01-19 12:53 ` Thomas Huth
2022-01-19 13:17 ` Janis Schoetterl-Glausch
2022-01-20 10:38 ` Thomas Huth
2022-01-20 11:20 ` Christian Borntraeger
2022-01-20 12:23 ` Janis Schoetterl-Glausch
2022-01-25 12:00 ` Thomas Huth
2022-01-27 16:29 ` Janis Schoetterl-Glausch
2022-01-27 17:34 ` Claudio Imbrenda
2022-01-18 9:52 ` [RFC PATCH v1 07/10] KVM: s390: Rename existing vcpu memop functions Janis Schoetterl-Glausch
2022-01-18 9:52 ` [RFC PATCH v1 08/10] KVM: s390: selftests: Test memops with storage keys Janis Schoetterl-Glausch
2022-01-18 9:52 ` [RFC PATCH v1 09/10] KVM: s390: Add capability for storage key extension of MEM_OP IOCTL Janis Schoetterl-Glausch
2022-01-18 15:12 ` Christian Borntraeger
2022-01-18 9:52 ` [RFC PATCH v1 10/10] KVM: s390: selftests: Make use of capability in MEM_OP test 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=YegQCTqEsiFTUZ2R@osiris \
--to=hca@linux.ibm.com \
--cc=agordeev@linux.ibm.com \
--cc=borntraeger@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=nrb@linux.ibm.com \
--cc=scgl@linux.ibm.com \
--cc=svens@linux.ibm.com \
/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;
as well as URLs for NNTP newsgroup(s).