linux-kernel - Re: [PATCH v4 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: <5d15fdf2-aee8-4e6c-c3e1-f07c76ce5974@linux.ibm.com>
Date:   Mon, 24 May 2021 10:37:29 -0400
From:   "Jason J. Herne" <jjherne@...ux.ibm.com>
To:     Tony Krowiak <akrowiak@...ux.ibm.com>, linux-s390@...r.kernel.org,
        linux-kernel@...r.kernel.org
Cc:     borntraeger@...ibm.com, cohuck@...hat.com,
        pasic@...ux.vnet.ibm.com, jgg@...dia.com,
        alex.williamson@...hat.com, kwankhede@...dia.com,
        frankja@...ux.ibm.com, david@...hat.com, imbrenda@...ux.ibm.com,
        hca@...ux.ibm.com
Subject: Re: [PATCH v4 2/2] s390/vfio-ap: control access to PQAP(AQIC)
 interception handler

On 5/21/21 3:36 PM, Tony Krowiak wrote:
> The function pointer to the handler that processes interception of the
> PQAP instruction is contained in the mdev. If the mdev is removed and
> its storage de-allocated during the processing of the PQAP instruction,
> the function pointer could get wiped out before the function is called
> because there is currently nothing that controls access to it.
> 
> This patch introduces two new functions:
> * The kvm_arch_crypto_register_hook() function registers a function pointer
>    for processing intercepted crypto instructions.
> * The kvm_arch_crypto_register_hook() function un-registers a function
>    pointer that was previously registered.

Typo: You meant kvm_arch_crypto_UNregister_hook() in the second bullet.

Just one overall observation on this one. The whole hook system seems kind of 
over-engineered if this is our only use for it. It looks like a kvm_s390_crypto_hook is 
meant to link a specific module with a function pointer. Do we really need this concept?

I think a simpler design could be to just place a mutex and a function pointer in the 
kvm_s390_crypto struct. Then you can grab the mutex in vfio_ap_ops.c when 
registering/unregistering. You would also grab the mutex in priv.c when calling the 
function pointer. What I am suggesting is essentially the exact same scheme you have 
implemented here, but simpler and with less infrastructure.

With that said, I'll point out that I am relative new to this code (and this patch series) 
so maybe I've missed something and the extra complexity is needed for some reason. But if 
it is not, I'm all in favor of keeping things simple.

-- 
-- Jason J. Herne (jjherne@...ux.ibm.com)