linux-kernel - Re: [RFC] KVM: arm/arm64: Introduce KVM_DEV_ARM_ITS_CTRL

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: <864ls5rz0h.fsf@arm.com>
Date:   Thu, 14 Sep 2017 18:06:06 +0100
From:   Marc Zyngier <marc.zyngier@....com>
To:     Eric Auger <eric.auger@...hat.com>
Cc:     <eric.auger.pro@...il.com>, <linux-kernel@...r.kernel.org>,
        <kvm@...r.kernel.org>, <cdall@...aro.org>,
        <peter.maydell@...aro.org>, <andre.przywara@....com>,
        <wanghaibin.wang@...wei.com>, <wu.wubin@...wei.com>
Subject: Re: [RFC] KVM: arm/arm64: Introduce KVM_DEV_ARM_ITS_CTRL_RESET

On Thu, Sep 14 2017 at 10:57:28 am BST, Eric Auger <eric.auger@...hat.com> wrote:
> At the moment, the in-kernel emulated ITS is not properly reset.
> On guest restart/reset some registers keep their old values and
> internal structures like device, ITE, collection lists are not emptied.
>
> This may lead to various bugs. Among them, we can have incorrect state
> backup or failure when saving the ITS state at early guest boot stage.
>
> This patch introduces a new attribute, KVM_DEV_ARM_ITS_CTRL_RESET in
> the KVM_DEV_ARM_VGIC_GRP_CTRL group.
>
> Upon this action, we can invalidate the various memory structures
> pointed by GITS_BASERn and GITS_CBASER, free the ITS internal caches
> and reset the relevant registers.
>
> Signed-off-by: Eric Auger <eric.auger@...hat.com>
>
> ---
>
> An alternative would consist in having the userspace writing
> individual registers with default values: GITS_BASERn, GITS_CBASER
> and GITS_CTLR. On kernel side we would reset related lists when
> detecting the valid bit is set to false.

I'm not sure this is necessarily a "either/or" situation. It looks to me
that we're not completely doing the right thing when writing to the
GITS_BASER registers, and that writing a new value (with the valid bit
set or not) should have an action of some sort on the fate of the
existing mappings.

Thoughts?

	M.
-- 
Jazz is not dead. It just smells funny.