linux-kernel - Re: [PATCH RFC 2/4] arm64: mm: Add RAS extension system register check to SEA handling

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]

Date:   Wed, 10 Jul 2019 00:51:46 +0000
From:   Tyler Baicar OS <baicar@...amperecomputing.com>
To:     James Morse <james.morse@....com>
CC:     Open Source Submission <patches@...erecomputing.com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
        "linux-edac@...r.kernel.org" <linux-edac@...r.kernel.org>,
        "catalin.marinas@....com" <catalin.marinas@....com>,
        "will@...nel.org" <will@...nel.org>,
        "lorenzo.pieralisi@....com" <lorenzo.pieralisi@....com>,
        "guohanjun@...wei.com" <guohanjun@...wei.com>,
        "sudeep.holla@....com" <sudeep.holla@....com>,
        "rjw@...ysocki.net" <rjw@...ysocki.net>,
        "lenb@...nel.org" <lenb@...nel.org>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "tony.luck@...el.com" <tony.luck@...el.com>,
        "bp@...en8.de" <bp@...en8.de>,
        "Matteo.Carlini@....com" <Matteo.Carlini@....com>,
        "Andrew.Murray@....com" <Andrew.Murray@....com>
Subject: Re: [PATCH RFC 2/4] arm64: mm: Add RAS extension system register
 check to SEA handling

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:
> > On systems that support the ARM RAS extension, synchronous external
> > abort syndrome information could be captured in the core's RAS extension
> > system registers. So, when handling SEAs check the RAS system registers
> > for error syndrome information.
>
> > diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
> > index 2d11501..76b42ca 100644
> > --- a/arch/arm64/mm/fault.c
> > +++ b/arch/arm64/mm/fault.c
> > @@ -37,6 +37,7 @@
> >  #include <asm/pgtable.h>
> >  #include <asm/tlbflush.h>
> >  #include <asm/traps.h>
> > +#include <asm/ras.h>
> > 
> >  struct fault_info {
> >       int     (*fn)(unsigned long addr, unsigned int esr,
> > @@ -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!

Thanks,
Tyler