linux-kernel - Re: [PATCH v3 7/8] arm64: exception: handle asynchronous SError interrupt

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] [day] [month] [year] [list]

Message-ID: <4cfa4f66-e9a2-fd52-fb64-b2510bcdf1d8@huawei.com>
Date:   Tue, 9 May 2017 10:16:32 +0800
From:   Xiongfeng Wang <wangxiongfeng2@...wei.com>
To:     James Morse <james.morse@....com>
CC:     Mark Rutland <mark.rutland@....com>,
        Xie XiuQi <xiexiuqi@...wei.com>, <christoffer.dall@...aro.org>,
        <marc.zyngier@....com>, <catalin.marinas@....com>,
        <will.deacon@....com>, <fu.wei@...aro.org>, <rostedt@...dmis.org>,
        <hanjun.guo@...aro.org>, <shiju.jose@...wei.com>,
        <wuquanming@...wei.com>, <kvm@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <gengdongjiu@...wei.com>,
        <linux-acpi@...r.kernel.org>, <zhengqiang10@...wei.com>,
        <kvmarm@...ts.cs.columbia.edu>,
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v3 7/8] arm64: exception: handle asynchronous SError
 interrupt

Hi James,

On 2017/5/9 1:27, James Morse wrote:
> Hi Xiongfeng Wang,
> 
> On 28/04/17 03:55, Xiongfeng Wang wrote:
>>>>>> It is ok to just ignore the process following the ESB instruction in el0_sync, because the process will be sent SIGBUS signal.
>>>>
>>>> I don't understand. How will Linux know the process caused an error if we
>>>> neither take an SError nor read DISR_EL1 after an ESB?
> 
>> I think there may be some misunderstanding here. The ESB instruction is placed in kernel_entry
>> of el0_sync and el0_irq. For the el0_sync, such as an syscall from userspace, after ESB is executed,
>> we check whether DISR.A is set. If it is not set, we go on to process the syscall. If it is set, we
>> jump to sError vector and then just eret.
> 
> Ah, this looks like an early optimisation!
> 
> We can't assume that the SError will result in the processing being killed, the
> AET bits of the SError ISS Encoding (page D7-2284 of ARM-ARM DDI0487B.a), has a
> 'corrected' error encoding.
> For these I would expect the SError-vector C code to do nothing and return to
> where it came from. In this case the syscall should still be run.
> 
Yes, it makes sense, so we should add a return value for the do_sei handler.

Thanks,
Wang Xiongfeng