| 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
| ||
|
Date: Thu, 11 Jul 2019 04:14:45 +0000
From: Tyler Baicar OS <baicar@...amperecomputing.com>
To: James Morse <james.morse@....com>,
"mark.rutland@....com" <mark.rutland@....com>
CC: "lorenzo.pieralisi@....com" <lorenzo.pieralisi@....com>,
"catalin.marinas@....com" <catalin.marinas@....com>,
"sudeep.holla@....com" <sudeep.holla@....com>,
"rjw@...ysocki.net" <rjw@...ysocki.net>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Matteo.Carlini@....com" <Matteo.Carlini@....com>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
"tony.luck@...el.com" <tony.luck@...el.com>,
"bp@...en8.de" <bp@...en8.de>,
"guohanjun@...wei.com" <guohanjun@...wei.com>,
"Andrew.Murray@....com" <Andrew.Murray@....com>,
Open Source Submission <patches@...erecomputing.com>,
"lenb@...nel.org" <lenb@...nel.org>,
"will@...nel.org" <will@...nel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-edac@...r.kernel.org" <linux-edac@...r.kernel.org>
Subject: Re: [PATCH RFC 2/4] arm64: mm: Add RAS extension system register
check to SEA handling
Hi James, Mark,
On Tue, Jul 9, 2019 at 8:52 PM Tyler Baicar OS <baicar@...amperecomputing.com> wrote:
> On Mon, Jul 8, 2019 at 10:10 AM James Morse <james.morse@....com> wrote:
> > On 02/07/2019 17:51, Tyler Baicar OS wrote:
> > > @@ -632,6 +633,8 @@ static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs)
> > >
> > > inf = esr_to_fault_info(esr);
> > >
> > > + arch_arm_ras_report_error();
> > > +
> > > /*
> > > * Return value ignored as we rely on signal merging.
> > > * Future patches will make this more robust.
> > >
> >
> > If we interrupted a preemptible context, do_sea() is preemptible too... This means we
> > can't know if we're still running on the same CPU as the one that took the external-abort.
> > (until this series, it hasn't mattered).
> >
> > Fixing this means cramming something into entry.S's el1_da, as this may unmask interrupts
> > before calling do_mem_abort(). But its going to be ugly because some of do_mem_abort()s
> > ESR values need to be preemptible because they sleep, e.g. page-faults calling
> > handle_mm_fault().
> > For do_sea(), do_exit() will 'fix' the preempt count if we kill the thread, but if we
> > don't, it still needs to be balanced. Doing all this in assembly is going to be unreadable!
> >
> > Mark Rutland has a series to move the entry assembly into C [0]. Based on that that it
> > should be possible for the new el1_abort() to spot a Synchronous-External-Abort ESR, and
> > wrap the do_mem_abort() with preempt enable/disable, before inheriting the flags. (which
> > for synchronous exceptions, I think we should always do)
> >
> > [0] https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/log/?h=arm64/entry-deasm
>
> Hey James,
>
> Good catch! I didn't think the synchronous route was preemptible.
>
> I wasn't seeing this issue when testing this on emulation, but I was able to
> test and prove the issue on a Neoverse N1 SDP:
>
> root@...ericarmv8:~# echo 0x100000000 > /proc/cached_read
> [ 42.985622] Reading from address 0x100000000
> [ 42.989893] WARNING: CPU: 0 PID: 2812 at /home/tyler/neoverse/arm-reference-
> platforms/linux/arch/arm64/kernel/cpufeature.c:1940 this_cpu_has_cap+0x68/0x78
> [..]
> [ 43.119083] Call trace:
> [ 43.121515] this_cpu_has_cap+0x68/0x78
> [ 43.125338] do_sea+0x34/0x70
> [ 43.128292] do_mem_abort+0x3c/0x98
> [ 43.131765] el1_da+0x20/0x94
> [ 43.134722] cached_read+0x30/0x68
> [ 43.138112] simple_attr_write+0xbc/0x128
> [ 43.142109] proc_reg_write+0x60/0xa8
> [ 43.145757] __vfs_write+0x18/0x40
> [ 43.149145] vfs_write+0xa4/0x1b8
> [ 43.152445] ksys_write+0x64/0xe0
> [ 43.155746] __arm64_sys_write+0x14/0x20
> [ 43.159654] el0_svc_common.constprop.0+0xa8/0x100
> [ 43.164430] el0_svc_handler+0x28/0x78
> [ 43.168165] el0_svc+0x8/0xc
> [ 43.171031] ---[ end trace 2c27619659261a1d ]---
> [ 43.175647] Internal error: synchronous external abort: 96000410 [#1]
> PREEMPT SMP
> [..]
>
> That warning is because it's preemptible:
>
> if (!WARN_ON(preemptible()) && n < ARM64_NCAPS) {
>
> I'll pull Mark's series in and add the preempt enable/disable around the call
> to do_mem_abort() in el1_abort() and test that out!
I was able to pull in the series mentioned [0] and add a patch to wrap
do_mem_abort with preempt disable/enable and the warning has gone away.
diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c
index 43aa78331e72..26cdf7db511a 100644
--- a/arch/arm64/kernel/entry-common.c
+++ b/arch/arm64/kernel/entry-common.c
@@ -118,7 +118,25 @@ static void el1_abort(struct pt_regs *regs, unsigned long esr)
unsigned long far = read_sysreg(far_el1);
local_daif_inherit(regs);
far = untagged_addr(far);
- do_mem_abort(far, esr, regs);
+
+ switch (esr & ESR_ELx_FSC) {
+ case ESR_ELx_FSC_EXTABT: // Synchronous External Abort
+ case 0x14: // SEA level 0 translation table walk
+ case 0x15: // SEA level 1 translation table walk
+ case 0x16: // SEA level 2 translation table walk
+ case 0x17: // SEA level 3 translation table walk
+ case 0x18: // Synchronous ECC error
+ case 0x1c: // SECC level 0 translation table walk
+ case 0x1d: // SECC level 1 translation table walk
+ case 0x1e: // SECC level 2 translation table walk
+ case 0x1f: // SECC level 3 translation table walk
+ preempt_disable();
+ do_mem_abort(far, esr, regs);
+ preempt_enable();
+ break;
+ default:
+ do_mem_abort(far, esr, regs);
+ };
}
/* Stack or PC alignment exception handling */
--
Is that what you had in mind James?
Has this series [0] been accepted and is just waiting to be pulled now?
Do you want me to add tested-by?
Thanks,
Tyler
[0] https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/log/?h=arm64/entry-deasm
Powered by blists - more mailing lists