linux-kernel - Re: [PATCH v2 06/10] KVM: arm/arm64: vgic-its: Always attempt to save/restore device and collection tables

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: <23010eed-f608-5d0e-3f82-ef07870fe80a@redhat.com>
Date:   Fri, 6 Oct 2017 17:29:47 +0200
From:   Auger Eric <eric.auger@...hat.com>
To:     Andre Przywara <andre.przywara@....com>, eric.auger.pro@...il.com,
        linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
        marc.zyngier@....com, cdall@...aro.org, peter.maydell@...aro.org,
        wanghaibin.wang@...wei.com
Cc:     wu.wubin@...wei.com
Subject: Re: [PATCH v2 06/10] KVM: arm/arm64: vgic-its: Always attempt to
 save/restore device and collection tables

Hi Andre,

On 06/10/2017 16:38, Andre Przywara wrote:
> Hi,
> 
> On 27/09/17 14:28, Eric Auger wrote:
>> In case the device table save fails, we currently do not
>> attempt to save the collection table. However it may
>> happen that the device table fails because the structures
>> in memory are inconsistent with device GITS_BASER however
>> this does not mean collection backup can't be performed and
>> wouldn't succeed. Same on restore path. Without this patch,
>> after a reset and in case the device table fails in case of
>> L1 entry not valid, the guest gets stuck on restore.
>>
>> Signed-off-by: Eric Auger <eric.auger@...hat.com>
>>
>> ---
>>
>> candidate to be CC'ed stable
>> ---
>>  virt/kvm/arm/vgic/vgic-its.c | 11 +++--------
>>  1 file changed, 3 insertions(+), 8 deletions(-)
>>
>> diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its.c
>> index 720552c..9e6b556 100644
>> --- a/virt/kvm/arm/vgic/vgic-its.c
>> +++ b/virt/kvm/arm/vgic/vgic-its.c
>> @@ -2304,12 +2304,9 @@ static int vgic_its_save_tables_v0(struct vgic_its *its)
>>  	}
>>  
>>  	ret = vgic_its_save_device_tables(its);
>> -	if (ret)
>> -		goto out;
>>  
>> -	ret = vgic_its_save_collection_table(its);
>> +	ret |= vgic_its_save_collection_table(its);
>>  
>> -out:
>>  	unlock_all_vcpus(kvm);
>>  	mutex_unlock(&its->its_lock);
>>  	mutex_unlock(&kvm->lock);
>> @@ -2336,11 +2333,9 @@ static int vgic_its_restore_tables_v0(struct vgic_its *its)
>>  	}
>>  
>>  	ret = vgic_its_restore_collection_table(its);
> 
> While the save functions above and this _v0 function here all use the
> standard C return semantics (==0 on success, failure otherwise),
> vgic_its_restore_collection_table() and the function call below can
> return 1 if successful, AFAICS. I don't think this handled correctly here?
After 01/10, vgic_its_restore_device_tables() can't return +1 anymore.
However you're right vgic_its_restore_collection_table can restore + 1
if the collection table is completely filled and this is wrong. I will
fix that.

Thanks

Eric
> 
> Cheers,
> Andre.
> 
>> -	if (ret)
>> -		goto out;
>>  
>> -	ret = vgic_its_restore_device_tables(its);
>> -out:
>> +	ret |= vgic_its_restore_device_tables(its);
>> +
>>  	unlock_all_vcpus(kvm);
>>  	mutex_unlock(&its->its_lock);
>>  	mutex_unlock(&kvm->lock);
>>