linux-kernel - Re: [PATCH v17 08/15] s390/vfio-ap: keep track of active guests

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 30 Dec 2021 03:04:19 +0100
From:   Halil Pasic <pasic@...ux.ibm.com>
To:     Tony Krowiak <akrowiak@...ux.ibm.com>
Cc:     linux-s390@...r.kernel.org, linux-kernel@...r.kernel.org,
        kvm@...r.kernel.org, jjherne@...ux.ibm.com, freude@...ux.ibm.com,
        borntraeger@...ibm.com, cohuck@...hat.com, mjrosato@...ux.ibm.com,
        alex.williamson@...hat.com, kwankhede@...dia.com,
        fiuczy@...ux.ibm.com, Halil Pasic <pasic@...ux.ibm.com>
Subject: Re: [PATCH v17 08/15] s390/vfio-ap: keep track of active guests

On Thu, 21 Oct 2021 11:23:25 -0400
Tony Krowiak <akrowiak@...ux.ibm.com> wrote:

> The reason a lockdep splat can occur has to do with the fact that the
> kvm->lock has to be taken before the vcpu->lock; so, for example, when a
> secure execution guest is started, you may end up with the following
> scenario:
> 
>         Interception of PQAP(AQIC) instruction executed on the guest:
>         ------------------------------------------------------------
>         handle_pqap:                    matrix_dev->lock                
>         kvm_vcpu_ioctl:                 vcpu_mutex                      
> 
>         Start of secure execution guest:
>         -------------------------------
>         kvm_s390_cpus_to_pv:            vcpu->mutex                     
>         kvm_arch_vm_ioctl:              kvm->lock                    
> 
>         Queue is unbound from vfio_ap device driver:
>         -------------------------------------------
>                                         kvm->lock
>         vfio_ap_mdev_remove_queue:      matrix_dev->lock

The way you describe your scenario is a little ambiguous. It
seems you choose a stack-trace like description, in a sense that for
example for PQAP: first vcpu->mutex is taken and then matrix_dev->lock
but you write the latter first and the former second. I think it is more
usual to describe such stuff a a sequence of event in a sense that
if A precedes B in the text (from the top towards the bottom), then
execution of a A precedes the execution of B in time.

Also you are inconsistent with vcpu_mutex vs vcpu->mutex.

I can't say I understand the need for this yet. I have been starring
at the end result for a while. Let me see if I can come up with an
alternate proposal for some things.

Regards,
Halil