linux-kernel - Re: [PATCH 7/9] KVM: arm/arm64: vgic-its: free caches when GITS

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]

Date:   Mon, 16 Oct 2017 10:47:35 +0100
From:   Peter Maydell <peter.maydell@...aro.org>
To:     Christoffer Dall <cdall@...aro.org>
Cc:     Eric Auger <eric.auger@...hat.com>, eric.auger.pro@...il.com,
        lkml - Kernel Mailing List <linux-kernel@...r.kernel.org>,
        kvm-devel <kvm@...r.kernel.org>,
        Marc Zyngier <marc.zyngier@....com>,
        Andre Przywara <andre.przywara@....com>,
        wanghaibin.wang@...wei.com, wu.wubin@...wei.com
Subject: Re: [PATCH 7/9] KVM: arm/arm64: vgic-its: free caches when GITS_BASER
 Valid bit is cleared

On 16 October 2017 at 10:26, Christoffer Dall <cdall@...aro.org> wrote:
> Hi Eric,
>
> On Mon, Sep 25, 2017 at 03:34:36PM +0200, Eric Auger wrote:
>> When the GITS_BASER<n>.Valid gets cleared, the data structures in
>> guest RAM are not provisionned anymore. The device, collection
>> and LPI lists stored in the in-kernel ITS represent the same
>> information in some form of cache. So let's void the cache.
>
> Just a thought.  What about the opposite case, if the BASERs were
> previously not valid, and then become valid, is the ITS expected restore
> the state from memory?

Architecturally speaking, it's a cache. As soon as the guest
turns the GITS_CTLR.Enabled bit on, the ITS is permitted to
start reading from the tables. It's an implementation choice
whether it wants to preload a bunch of stuff, only load it
up when it becomes necessary or even leave it all in memory
and cache nothing.

Eric wrote:
> Also the spec does not mandate clearing the cache when BASER
> moves to invalid (which this patch does), although this would
> have made sense to me.

The spec says that messing with GITS_BASER while GITS_CTRL.Enabled
is set or GITS_CTLR.Quiescent is 0 is UNPREDICTABLE. And it
says that once the OS has done the Enabled/Quiescent handshake
then the ITS must have written out any dirty data to memory
and stopped doing anything. So the effect is that BASER
can't ever move to invalid while the caches are dirty.

thanks
-- PMM