linux-kernel - Re: [PATCH v10 13/19] KVM: s390: pv: destroy the configuration before its memory

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: <96ee2d8c2c64b4968529b78bd7ad8a042542d353.camel@linux.ibm.com>
Date:   Mon, 30 May 2022 09:37:37 +0200
From:   Nico Boehr <nrb@...ux.ibm.com>
To:     Claudio Imbrenda <imbrenda@...ux.ibm.com>, kvm@...r.kernel.org
Cc:     borntraeger@...ibm.com, frankja@...ux.ibm.com, thuth@...hat.com,
        pasic@...ux.ibm.com, david@...hat.com, linux-s390@...r.kernel.org,
        linux-kernel@...r.kernel.org, scgl@...ux.ibm.com,
        mimu@...ux.ibm.com
Subject: Re: [PATCH v10 13/19] KVM: s390: pv: destroy the configuration
 before its memory

On Thu, 2022-04-14 at 10:03 +0200, Claudio Imbrenda wrote:
> Move the Destroy Secure Configuration UVC before the loop to destroy
> the memory. If the protected VM has memory, it will be cleaned up and
> made accessible by the Destroy Secure Configuraion UVC. The struct
> page for the relevant pages will still have the protected bit set, so
> the loop is still needed to clean that up.
> 
> Switching the order of those two operations does not change the
> outcome, but it is significantly faster.
> 
> Signed-off-by: Claudio Imbrenda <imbrenda@...ux.ibm.com>

Reviewed-by: Nico Boehr <nrb@...ux.ibm.com>

See one tiny thing below.

> diff --git a/arch/s390/kvm/pv.c b/arch/s390/kvm/pv.c
> index be3b467f8feb..bd850be08c86 100644
> --- a/arch/s390/kvm/pv.c
> +++ b/arch/s390/kvm/pv.c
[...]
> -       cc = uv_cmd_nodata(kvm_s390_pv_get_handle(kvm),
> -                          UVC_CMD_DESTROY_SEC_CONF, rc, rrc);
>         WRITE_ONCE(kvm->arch.gmap->guest_handle, 0);

Maybe it makes sense to also move the WRITE_ONCE up.