linux-kernel - Re: [PATCH v1 1/2] KVM: s390: Tracing APCB changes

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: <20181005113053.7a3e1f72.cohuck@redhat.com>
Date:   Fri, 5 Oct 2018 11:30:53 +0200
From:   Cornelia Huck <cohuck@...hat.com>
To:     Pierre Morel <pmorel@...ux.ibm.com>
Cc:     borntraeger@...ibm.com, david@...hat.com,
        linux-kernel@...r.kernel.org, linux-s390@...r.kernel.org,
        kvm@...r.kernel.org, frankja@...ux.ibm.com, akrowiak@...ux.ibm.com,
        pasic@...ux.ibm.com
Subject: Re: [PATCH v1 1/2] KVM: s390: Tracing APCB changes

On Fri, 5 Oct 2018 10:57:22 +0200
Pierre Morel <pmorel@...ux.ibm.com> wrote:

> On 05/10/2018 10:49, Cornelia Huck wrote:
> > On Fri,  5 Oct 2018 10:31:09 +0200
> > Pierre Morel <pmorel@...ux.ibm.com> wrote:
> >   
> >> kvm_arch_crypto_set_masks is a new function to centralize
> >> the setup the APCB masks inside the CRYCB SIE satelite.  
> > 
> > s/satelite/satellite/
> >   
> >>
> >> To trace APCB mask changes, we add KVM_EVENT() tracing to
> >> both kvm_arch_crypto_set_masks and kvm_arch_crypto_clear_masks.
> >>
> >> Signed-off-by: Pierre Morel <pmorel@...ux.ibm.com>
> >> ---
> >>   arch/s390/include/asm/kvm_host.h |  2 ++
> >>   arch/s390/kvm/kvm-s390.c         | 41 ++++++++++++++++++++++++++++++++++++++++
> >>   2 files changed, 43 insertions(+)

(...)

> > The locking and requests makes me wonder if we missed them before...
> > were they simply not needed for the prior use case (mdev group
> > notifier)?  
> 
> Before we used to set the mask before creating the vcpu.
> In fact since we still call this function from the initialization
> of VFIO AP we still do.
> 
> But since this function is more generic we need to be more careful
> if it is called when vcpu are running.
> We do the same locking mechanism in the kvm_arch_crypto_clear_mask().

Yes, that makes sense.

Reviewed-by: Cornelia Huck <cohuck@...hat.com>