linux-kernel - Re: [PATCH] KVM: arm/arm64: vgic-its: Fix restoration of unmapped collections

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] [day] [month] [year] [list]

Message-ID: <066e4f57-9f92-2bd6-130a-b3c8bb0dcfc4@huawei.com>
Date:   Fri, 13 Dec 2019 22:22:46 +0800
From:   Zenghui Yu <yuzenghui@...wei.com>
To:     Marc Zyngier <maz@...nel.org>
CC:     Eric Auger <eric.auger@...hat.com>, <eric.auger.pro@...il.com>,
        <linux-kernel@...r.kernel.org>, <kvmarm@...ts.cs.columbia.edu>
Subject: Re: [PATCH] KVM: arm/arm64: vgic-its: Fix restoration of unmapped
 collections

Hi Marc,

On 2019/12/13 19:28, Marc Zyngier wrote:
> Hi Zenghui,
> 
> On 2019-12-13 10:53, Zenghui Yu wrote:
>> Hi Eric,
>>
>> On 2019/12/13 17:42, Eric Auger wrote:
>>> Saving/restoring an unmapped collection is a valid scenario. For
>>> example this happens if a MAPTI command was sent, featuring an
>>> unmapped collection. At the moment the CTE fails to be restored.
>>> Only compare against the number of online vcpus if the rdist
>>> base is set.
>>
>> Have you actually seen a problem and this patch fixed it? To be honest,
>> I'm surprised to find that we can map a LPI to an unmapped collection ;)
>> (and prevent it to be delivered to vcpu with an INT_UNMAPPED_INTERRUPT
>> error, until someone had actually mapped the collection).
>> After a quick glance of spec (MAPTI), just as you said, this is valid.
> 
> Yes, this is one of the (many) odd bits in the architecture. And there is
> a bizarre wording in the MAPC description when V=0:
> 
> "Behavior is unpredictable if there are interrupts that are mapped to the
> specified collection, with the restriction that further translation 
> requests
> from that device are ignored."
> 
> It is really odd that:
> 
> - it is unpredictable to unmap the collection with mapped interrupts,
>    but mapping interrupts to an unmapped collection is fine

Yes, looks odd... Without Eric's patch, I won't even notice it.

I guess that unmapping the collection with mapped interrupts will make
it difficult for Hardware to manage those interrupts' internal states,
but only a guess.

> - the notion of "interrupts from that device" doesn't match any of the
>    MAPC parameters

Looks like a writing mistake, a better statement *might be*
"further translation requests targeting that ICID are ignored"?

> Do you hate the GIC already? ;-)

Not yet! (I'd like to continue being messed with GIC and see when I
will hate it :)

> 
>> If Marc has no objection to this fix, please add
>>
>> Reviewed-by: Zenghui Yu <yuzenghui@...wei.com>
> 
> Thanks for that, I've applied it to the patch and will push out
> the update as soon as ra.kernel.org is reachable again.

Thanks,
Zenghui