linux-kernel - Re: gic_write_grpen1 in hotplug flow

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <c9231770-2663-fb4a-fec4-1ad2765e8c54@arm.com>
Date:   Thu, 4 May 2017 10:17:33 +0100
From:   Sudeep Holla <sudeep.holla@....com>
To:     Sodagudi Prasad <psodagud@...eaurora.org>
Cc:     marc.zyngier@....com, will.deacon@....com,
        Sudeep Holla <sudeep.holla@....com>,
        Jason Cooper <jason@...edaemon.net>,
        Thomas Gleixner <tglx@...utronix.de>,
        linux-kernel@...r.kernel.org
Subject: Re: gic_write_grpen1 in hotplug flow

Hi Prasad,

On 04/05/17 02:30, Sodagudi Prasad wrote:
> Hi All,
> 
> This is regarding the usage of gic_write_grpen1 API usage in
> irq-gic-v3 driver.
> 
> Here my understanding about ICC_IGRPEN1_EL1. ICC_IGRPEN1_EL1 is
> banked between secure and non-secure states. If two secure states are
> implemented, Secure side Group bit is set by the platform firmware
> (PSCI) and kernel need to set in non secure state. 
> https://mail.codeaurora.org/?_task=mail&_action=compose&_id=676833541590a775943df6#
>

Are you referring to something with the above link ? If so, it's not
accessible

> 1) Currently gic_write_grpen1(0) is getting called from 
> gic_cpu_pm_notifier() for CPU_PM_ENTER in single security state
> only. But enabling of group1 non-secure interrupts are done in
> CPU_PM_EXIT path unconditionally. Why are we not disabling group1
> non-secure interrupts unconditionally in CPU_PM_ENTER(and disabling
> only in single security state)?
> 

If you read the log in commit ccd9432a5c85 ("irqchip/gicv3: Remove
disabling redistributor and group1 non-secure interrupts"), it clearly
states the reason. In fact it was required to support RETENTION states
on some Qualcomm parts itself. So in short, we enable in CPU_PM_EXIT
path unconditionally just to be sure. It can be made conditional but
not a hard requirement while not disabling in CPU_PM_ENTER is.

> 2) Why group1 non-secure interrupts are not disabled in kernel
> during cpu hotplug path? Spurious interrupt can still come if we dont
> disable group1 non-secure interrupts, right?
> 

As per PSCI specification: "Unlike CPU_SUSPEND , CPU_OFF is not expected
to return". We disable local CPI interrupt mask before CPU_OFF. We can
re-enter only with CPU_ON call, so I don't see possibility of any issues
with that. Are you observing any issues ?

-- 
Regards,
Sudeep