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: <5a5bfa6a-30e6-a6dd-4482-29f27888d823@arm.com>
Date:   Mon, 10 Jun 2019 12:36:45 +0100
From:   Julien Thierry <julien.thierry@....com>
To:     Marc Zyngier <marc.zyngier@....com>,
        linux-arm-kernel@...ts.infradead.org
Cc:     linux-kernel@...r.kernel.org, rostedt@...dmis.org,
        yuzenghui@...wei.com, wanghaibin.wang@...wei.com,
        james.morse@....com, will.deacon@....com, catalin.marinas@....com,
        mark.rutland@....com, liwei391@...wei.com,
        Christoffer Dall <christoffer.dall@....com>,
        Suzuki K Pouloze <suzuki.poulose@....com>,
        Oleg Nesterov <oleg@...hat.com>
Subject: Re: [PATCH v3 5/8] arm64: Fix incorrect irqflag restore for priority
 masking



On 10/06/2019 08:49, Julien Thierry wrote:
> 
> 
> On 07/06/2019 17:29, Marc Zyngier wrote:
>> On 06/06/2019 10:31, Julien Thierry wrote:
>>> When using IRQ priority masking to disable interrupts, in order to deal
>>> with the PSR.I state, local_irq_save() would convert the I bit into a
>>> PMR value (GIC_PRIO_IRQOFF). This resulted in local_irq_restore()
>>> potentially modifying the value of PMR in undesired location due to the
>>> state of PSR.I upon flag saving [1].
>>>
>>> In an attempt to solve this issue in a less hackish manner, introduce
>>> a bit (GIC_PRIO_IGNORE_PMR) for the PMR values that can represent
>>> whether PSR.I is being used to disable interrupts, in which case it
>>> takes precedence of the status of interrupt masking via PMR.
>>>
>>> GIC_PRIO_IGNORE_PMR is chosen such that (<pmr_value> |
>>> GIC_PRIO_IGNORE_PMR) does not mask more interrupts than <pmr_value> as
>>> some sections (e.g. arch_cpu_idle(), interrupt acknowledge path)
>>> requires PMR not to mask interrupts that could be signaled to the
>>> CPU when using only PSR.I.
>>>
>>
>> s/GIC_PRIO_IGNORE_PMR/GIC_PRIO_PSR_I_SET/
>>
>>> [1] https://www.spinics.net/lists/arm-kernel/msg716956.html
>>>
>>> Fixes: commit 4a503217ce37 ("arm64: irqflags: Use ICC_PMR_EL1 for interrupt masking")
>>> Signed-off-by: Julien Thierry <julien.thierry@....com>
>>> Reported-by: Zenghui Yu <yuzenghui@...wei.com>
>>> Cc: Steven Rostedt <rostedt@...dmis.org>
>>> Cc: Wei Li <liwei391@...wei.com>
>>> Cc: Catalin Marinas <catalin.marinas@....com>
>>> Cc: Will Deacon <will.deacon@....com>
>>> Cc: Christoffer Dall <christoffer.dall@....com>
>>> Cc: Marc Zyngier <marc.zyngier@....com>
>>> Cc: James Morse <james.morse@....com>
>>> Cc: Suzuki K Pouloze <suzuki.poulose@....com>
>>> Cc: Oleg Nesterov <oleg@...hat.com>
>>> ---
>>>  arch/arm64/include/asm/arch_gicv3.h |  4 ++-
>>>  arch/arm64/include/asm/daifflags.h  | 68 ++++++++++++++++++++++---------------
>>>  arch/arm64/include/asm/irqflags.h   | 67 +++++++++++++++---------------------
>>>  arch/arm64/include/asm/kvm_host.h   |  7 ++--
>>>  arch/arm64/include/asm/ptrace.h     | 10 ++++--
>>>  arch/arm64/kernel/entry.S           | 38 ++++++++++++++++++---
>>>  arch/arm64/kernel/process.c         |  2 +-
>>>  arch/arm64/kernel/smp.c             |  8 +++--
>>>  arch/arm64/kvm/hyp/switch.c         |  2 +-
>>>  9 files changed, 123 insertions(+), 83 deletions(-)
>>>

[...]

>>> diff --git a/arch/arm64/include/asm/irqflags.h b/arch/arm64/include/asm/irqflags.h
>>> index fbe1aba..b6f757f 100644
>>> --- a/arch/arm64/include/asm/irqflags.h
>>> +++ b/arch/arm64/include/asm/irqflags.h
>>> @@ -67,43 +67,46 @@ static inline void arch_local_irq_disable(void)
>>>   */
>>>  static inline unsigned long arch_local_save_flags(void)
>>>  {
>>> -	unsigned long daif_bits;
>>>  	unsigned long flags;
>>>
>>> -	daif_bits = read_sysreg(daif);
>>> -
>>> -	/*
>>> -	 * The asm is logically equivalent to:
>>> -	 *
>>> -	 * if (system_uses_irq_prio_masking())
>>> -	 *	flags = (daif_bits & PSR_I_BIT) ?
>>> -	 *			GIC_PRIO_IRQOFF :
>>> -	 *			read_sysreg_s(SYS_ICC_PMR_EL1);
>>> -	 * else
>>> -	 *	flags = daif_bits;
>>> -	 */
>>>  	asm volatile(ALTERNATIVE(
>>> -			"mov	%0, %1\n"
>>> -			"nop\n"
>>> -			"nop",
>>> -			__mrs_s("%0", SYS_ICC_PMR_EL1)
>>> -			"ands	%1, %1, " __stringify(PSR_I_BIT) "\n"
>>> -			"csel	%0, %0, %2, eq",
>>> -			ARM64_HAS_IRQ_PRIO_MASKING)
>>> -		: "=&r" (flags), "+r" (daif_bits)
>>> -		: "r" ((unsigned long) GIC_PRIO_IRQOFF)
>>> -		: "cc", "memory");
>>> +		"mrs	%0, daif",
>>> +		__mrs_s("%0", SYS_ICC_PMR_EL1),
>>> +		ARM64_HAS_IRQ_PRIO_MASKING)
>>> +		: "=&r" (flags)
>>> +		:
>>> +		: "memory");
>>
>> I think this is worth a comment here, as you're changing the semantics
>> of arch_local_save_flags(). Maybe just indicating that the only thing
>> this should be used for is to carry the interrupt state, and nothing else.
>>
> 
> Arguably, this is what gets called by local_save_flags() which is arch
> independent and, as far as I understand, is only aware of the interrupt
> state being contained in the flags (arch might wish to store more stuff
> in it, but overall, generic code cannot rely on it).
> 
> I'll still add a comment so that code directly calling arch_save_flags()
> doesn't try to play with PSR.DA_F. (In such a cases it would be probably
> clearer for them to do direct DAIF reads/writes IMO).
> 

After checking, arch_local_save_flags() already has the following
comment above it:

/*



 * Save the current interrupt enable state.



 */


Which suggests you shouldn't rely on having the value of debug state and
other (it just happens to be there, maybe wrongfully...).

And user checking the flags should use arch_irqs_disabled_flags() rather
than "flags & PSR_I_BIT != 0".

Also, those semantics where already changed when we introduced priority
masking and included the PMR value in the irqflags.

I'm not sure there is a lot more explanation to do in this patch in
particular.

Thanks,

-- 
Julien Thierry

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ