linux-kernel - Re: [PATCH v3 2/2] s390/vfio-ap: control access to PQAP(AQIC) interception handler

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]

Message-ID: <20210520104857.65d75858.pasic@linux.ibm.com>
Date:   Thu, 20 May 2021 10:48:57 +0200
From:   Halil Pasic <pasic@...ux.ibm.com>
To:     Tony Krowiak <akrowiak@...ux.ibm.com>
Cc:     Jason Gunthorpe <jgg@...dia.com>, linux-s390@...r.kernel.org,
        linux-kernel@...r.kernel.org, borntraeger@...ibm.com,
        cohuck@...hat.com, pasic@...ux.vnet.ibm.com, jjherne@...ux.ibm.com,
        alex.williamson@...hat.com, kwankhede@...dia.com
Subject: Re: [PATCH v3 2/2] s390/vfio-ap: control access to PQAP(AQIC)
 interception handler

On Wed, 19 May 2021 21:08:15 -0400
Tony Krowiak <akrowiak@...ux.ibm.com> wrote:

> >
> > This is nonesense too:
> >
> > 	if (vcpu->kvm->arch.crypto.pqap_hook) {
> > 		if (!try_module_get(vcpu->kvm->arch.crypto.pqap_hook->owner))
> > 			return -EOPNOTSUPP;
> > 		ret = vcpu->kvm->arch.crypto.pqap_hook->hook(vcpu);
> >
> > It should have a lock around it of some kind, not a
> > try_module_get. module_get is not la lock.  
> 
> As I said earlier, I don't know why the author did this. 

Please have a look at these links from the archive to get some
perspective:
https://lkml.org/lkml/2020/12/4/994
https://lkml.org/lkml/2020/12/3/987
https://www.lkml.org/lkml/2019/3/1/260

We can ask the original author, but I don't think we have to. BTW the
patch that introduced it has your r-b.

> My best guess
> is that he wanted to ensure that the module was still loaded; otherwise,
> the data structures contained therein - for example, the pqap_hook
> and matrix_mdev that contains it - would be gonzo.

More precisely prevent the module from unloading while we execute code
from it. As I've pointed out in a previous email the module may be gone
by the time we call try_module_get().

Regards,
Halil