[GIT PULL 0/1] KVM: s390: Fix lockdep issue in vm memop

[GIT PULL 0/1] KVM: s390: Fix lockdep issue in vm memop

[Christian Borntraeger]

Paolo,

one patch that is sitting already too long in my tree (sorry, was out of
office some days).

The following changes since commit 3bcc372c9865bec3ab9bfcf30b2426cf68bc18af:

  KVM: s390: selftests: Add error memop tests (2022-03-14 16:12:27 +0100)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux.git  tags/kvm-s390-master-5.18-1

for you to fetch changes up to 4aa5ac75bf79cbbc46369163eb2e3addbff0d434:

  KVM: s390: Fix lockdep issue in vm memop (2022-03-23 10:41:04 +0100)

----------------------------------------------------------------
KVM: s390: fix lockdep warning in new MEMOP call

----------------------------------------------------------------
Janis Schoetterl-Glausch (1):
      KVM: s390: Fix lockdep issue in vm memop

 arch/s390/kvm/kvm-s390.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

[GIT PULL 1/1] KVM: s390: Fix lockdep issue in vm memop

[Christian Borntraeger]

From: Janis Schoetterl-Glausch <scgl@linux.ibm.com>

Issuing a vm memop on a protected vm does not make sense,
neither is the memory readable/writable, nor does it make sense to check
storage keys. This is why the ioctl will return -EINVAL when it detects
the vm to be protected. However, in order to ensure that the vm cannot
become protected during the memop, the kvm->lock would need to be taken
for the duration of the ioctl. This is also required because
kvm_s390_pv_is_protected asserts that the lock must be held.
Instead, don't try to prevent this. If user space enables secure
execution concurrently with a memop it must accecpt the possibility of
the memop failing.
Still check if the vm is currently protected, but without locking and
consider it a heuristic.

Fixes: ef11c9463ae0 ("KVM: s390: Add vm IOCTL for key checked guest absolute memory access")
Signed-off-by: Janis Schoetterl-Glausch <scgl@linux.ibm.com>
Reviewed-by: Janosch Frank <frankja@linux.ibm.com>
Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Link: https://lore.kernel.org/r/20220322153204.2637400-1-scgl@linux.ibm.com
Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
---
 arch/s390/kvm/kvm-s390.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
index b53ff693b66e..7240a781ea82 100644
--- a/arch/s390/kvm/kvm-s390.c
+++ b/arch/s390/kvm/kvm-s390.c
@@ -2385,7 +2385,16 @@ static int kvm_s390_vm_mem_op(struct kvm *kvm, struct kvm_s390_mem_op *mop)
 		return -EINVAL;
 	if (mop->size > MEM_OP_MAX_SIZE)
 		return -E2BIG;
-	if (kvm_s390_pv_is_protected(kvm))
+	/*
+	 * This is technically a heuristic only, if the kvm->lock is not
+	 * taken, it is not guaranteed that the vm is/remains non-protected.
+	 * This is ok from a kernel perspective, wrongdoing is detected
+	 * on the access, -EFAULT is returned and the vm may crash the
+	 * next time it accesses the memory in question.
+	 * There is no sane usecase to do switching and a memop on two
+	 * different CPUs at the same time.
+	 */
+	if (kvm_s390_pv_get_handle(kvm))
 		return -EINVAL;
 	if (mop->flags & KVM_S390_MEMOP_F_SKEY_PROTECTION) {
 		if (access_key_invalid(mop->key))
-- 
2.35.1

Re: [GIT PULL 0/1] KVM: s390: Fix lockdep issue in vm memop

[Paolo Bonzini]

On 5/2/22 17:30, Christian Borntraeger wrote:
> Paolo,
> 
> one patch that is sitting already too long in my tree (sorry, was out of
> office some days).

Hi Christian,

at this point I don't have much waiting for 5.18.  Feel free to send it 
through the s390 tree.

Paolo

> The following changes since commit 3bcc372c9865bec3ab9bfcf30b2426cf68bc18af:
> 
>    KVM: s390: selftests: Add error memop tests (2022-03-14 16:12:27 +0100)
> 
> are available in the Git repository at:
> 
>    git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux.git  tags/kvm-s390-master-5.18-1
> 
> for you to fetch changes up to 4aa5ac75bf79cbbc46369163eb2e3addbff0d434:
> 
>    KVM: s390: Fix lockdep issue in vm memop (2022-03-23 10:41:04 +0100)
> 
> ----------------------------------------------------------------
> KVM: s390: fix lockdep warning in new MEMOP call
> 
> ----------------------------------------------------------------
> Janis Schoetterl-Glausch (1):
>        KVM: s390: Fix lockdep issue in vm memop
> 
>   arch/s390/kvm/kvm-s390.c | 11 ++++++++++-
>   1 file changed, 10 insertions(+), 1 deletion(-)
> 

Re: [GIT PULL 0/1] KVM: s390: Fix lockdep issue in vm memop

[Christian Borntraeger]

Am 02.05.22 um 17:39 schrieb Paolo Bonzini:
> On 5/2/22 17:30, Christian Borntraeger wrote:
>> Paolo,
>>
>> one patch that is sitting already too long in my tree (sorry, was out of
>> office some days).
> 
> Hi Christian,
> 
> at this point I don't have much waiting for 5.18.  Feel free to send it through the s390 tree.

OK.

Heiko, Vasily, can you queue this for your next pull request?

Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
for carrying this via the s390 tree.

> 
> Paolo
> 
>> The following changes since commit 3bcc372c9865bec3ab9bfcf30b2426cf68bc18af:
>>
>>    KVM: s390: selftests: Add error memop tests (2022-03-14 16:12:27 +0100)
>>
>> are available in the Git repository at:
>>
>>    git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux.git  tags/kvm-s390-master-5.18-1
>>
>> for you to fetch changes up to 4aa5ac75bf79cbbc46369163eb2e3addbff0d434:
>>
>>    KVM: s390: Fix lockdep issue in vm memop (2022-03-23 10:41:04 +0100)
>>
>> ----------------------------------------------------------------
>> KVM: s390: fix lockdep warning in new MEMOP call
>>
>> ----------------------------------------------------------------
>> Janis Schoetterl-Glausch (1):
>>        KVM: s390: Fix lockdep issue in vm memop
>>
>>   arch/s390/kvm/kvm-s390.c | 11 ++++++++++-
>>   1 file changed, 10 insertions(+), 1 deletion(-)
>>
> 

Re: [GIT PULL 0/1] KVM: s390: Fix lockdep issue in vm memop

[Heiko Carstens]

On Mon, May 02, 2022 at 05:41:13PM +0200, Christian Borntraeger wrote:
> Am 02.05.22 um 17:39 schrieb Paolo Bonzini:
> > On 5/2/22 17:30, Christian Borntraeger wrote:
> > > Paolo,
> > > 
> > > one patch that is sitting already too long in my tree (sorry, was out of
> > > office some days).
> > 
> > Hi Christian,
> > 
> > at this point I don't have much waiting for 5.18.  Feel free to send it through the s390 tree.
> 
> OK.
> 
> Heiko, Vasily, can you queue this for your next pull request?
> 
> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
> for carrying this via the s390 tree.

It's now on the fixes branch:
https://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git/log/?h=fixes

Actually I was waiting if some fixes would come in, since the fixes
branch also had only one small fix until now.