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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 8 Oct 2021 09:01:15 +0100 From: Will Deacon <will@...nel.org> To: Huangzhaoyang <huangzhaoyang@...il.com> Cc: Catalin Marinas <catalin.marinas@....com>, Mark Rutland <mark.rutland@....com>, Suzuki K Poulose <suzuki.poulose@....com>, Ionela Voinescu <ionela.voinescu@....com>, Quentin Perret <qperret@...gle.com>, Vladimir Murzin <vladimir.murzin@....com>, linux-arm-kernel@...ts.infradead.org, Zhaoyang Huang <zhaoyang.huang@...soc.com>, linux-kernel@...r.kernel.org, ke.wang@...soc.com Subject: Re: [RFC PATCH] arch: ARM64: add isb before enable pan Hi, On Fri, Oct 08, 2021 at 02:07:49PM +0800, Huangzhaoyang wrote: > From: Zhaoyang Huang <zhaoyang.huang@...soc.com> > > set_pstate_pan failure is observed in an ARM64 system occasionaly on a reboot > test, which can be work around by a msleep on the sw context. We assume > suspicious on disorder of previous instr of disabling SW_PAN and add an isb here. > > PS: > The bootup test failed with a invalid TTBR1_EL1 that equals 0x34000000, which is > alike racing between on chip PAN and SW_PAN. Sorry, but I'm struggling to understand the problem here. Please could you explain it in more detail? - Why does a TTBR1_EL1 value of `0x34000000` indicate a race? - Can you explain the race that you think might be occurring? - Why does an ISB prevent the race? > Signed-off-by: Zhaoyang Huang <zhaoyang.huang@...soc.com> > --- > arch/arm64/kernel/cpufeature.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c > index efed283..3c0de0d 100644 > --- a/arch/arm64/kernel/cpufeature.c > +++ b/arch/arm64/kernel/cpufeature.c > @@ -1663,6 +1663,7 @@ static void cpu_enable_pan(const struct arm64_cpu_capabilities *__unused) > WARN_ON_ONCE(in_interrupt()); > > sysreg_clear_set(sctlr_el1, SCTLR_EL1_SPAN, 0); > + isb(); > set_pstate_pan(1); SCTLR_EL1.SPAN only affects the PAN behaviour on taking an exception, which is itself a context-synchronizing event, so I can't see why the ISB makes any difference here (at least, for the purposes of PAN). Thanks, Will
Powered by blists - more mailing lists