linux-kernel - Re: [PATCH] irqchip/gicv3: Fix GICR_WAKE & GICD

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, 6 Feb 2017 09:33:08 +0000
From:   Marc Zyngier <marc.zyngier@....com>
To:     Shanker Donthineni <shankerd@...eaurora.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>
Cc:     Christoffer Dall <christoffer.dall@...aro.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Jason Cooper <jason@...edaemon.net>,
        Vikram Sethi <vikrams@...eaurora.org>
Subject: Re: [PATCH] irqchip/gicv3: Fix GICR_WAKE & GICD_IGROUPR accesses from
 non-secure

Hi Shanker,

On 06/02/17 02:17, Shanker Donthineni wrote:
> On systems where it supports two security states, both the register
> GICR_WAKE and GICD_IGROUPR accesses are RAZ/WI from non-secure.
> The function gic_enable_redist() to wake/sleep redistributor is not
> harmful at all, but it is confusing looking at the code. The current
> code checks the single security state based on bit GICD_CTLR.DS which
> is absolutely incorrect. The disable security bit GICD_CTLR.DS is RAZ
> to non-secure.

I'm afraid we don't have the same definition of GICD_CTLR.DS. In my copy
of the architecture spec, it says:

"When this field is set to 1, all accesses to GICD_CTLR access the
single Security state view, and all bits are accessible".
                                ^^^^^^^^^^^^^^^^^^^^^^^

This would tend to support my interpretation that once DS has been set
from the secure side, it becomes visible to all type of accesses.

> The GICD_TYPE.SecurityExtn indicates whether the GIC
> implementation supports two security states or only one security
> state.

Yes, and that's orthogonal to having set DS or not.

So clearly, we have a difference of interpretation. What part of the
spec is supporting yours?

Thanks,

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