linux-kernel - Re: [PATCH] irqchip/gic-v3: Fix GICD_CTLR_ARE

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]

Date:   Tue, 07 Mar 2017 13:36:07 +0530
From:   Alim Akhtar <alim.akhtar@...sung.com>
To:     Marc Zyngier <marc.zyngier@....com>
Cc:     linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        andre.przywara@....com, christoffer.dall@...aro.org,
        vladimir.murzin@....com, Alim Akhtar <alim.akhtar@...il.com>,
        stable@...r.kernel.org
Subject: Re: [PATCH] irqchip/gic-v3: Fix GICD_CTLR_ARE_NS bit field

Hi Marc,

On 03/07/2017 01:11 PM, Marc Zyngier wrote:
> On Tue, Mar 07 2017 at  4:07:05 am GMT, Alim Akhtar <alim.akhtar@...sung.com> wrote:
>> From: Alim Akhtar <alim.akhtar@...il.com>
>>
>> As per GICv3 Architecture specification 8.9.4 field descriptions,
>> GICD_CTLR_ARE_NS is bit[5]. This patch correct the same.
>>
>> Fixes: 021f6537 ("irqchip: gic-v3: Initial support for GICv3")
>> Cc: stable@...r.kernel.org
>> Signed-off-by: Alim Akhtar <alim.akhtar@...sung.com>
>> ---
>>  include/linux/irqchip/arm-gic-v3.h | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/include/linux/irqchip/arm-gic-v3.h b/include/linux/irqchip/arm-gic-v3.h
>> index e808f8a..4aaf639 100644
>> --- a/include/linux/irqchip/arm-gic-v3.h
>> +++ b/include/linux/irqchip/arm-gic-v3.h
>> @@ -57,7 +57,7 @@
>>
>>  #define GICD_CTLR_RWP			(1U << 31)
>>  #define GICD_CTLR_DS			(1U << 6)
>> -#define GICD_CTLR_ARE_NS		(1U << 4)
>> +#define GICD_CTLR_ARE_NS		(1U << 5)
>>  #define GICD_CTLR_ENABLE_G1A		(1U << 1)
>>  #define GICD_CTLR_ENABLE_G1		(1U << 0)
>
> No, the issue is much more subtle.
>
> - When the access is secure in a system that supports two security
>   states, this is bit[5] indeed.
>
> - When the access is non-secure in a system that supports two security
>   states, this is bit[4] (so that software written for a single security
>   mode can run on both side of the security fence).
>
> - In a system that only supports a single security state, this is bit[4]
>   too.
>
> Given that Linux is only designed to run on the non-secure side (at
> least when paired with GICv3), I stand by my original bit layout.
>
Ok, got it, thanks for clarification.

> Thanks,
>
>         M.
>