linux-kernel - Re: [PATCH V3 05/10] acpi: apei: handle SEA notification type for ARMv8

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]

Date:   Sun, 23 Oct 2016 17:13:28 +0800
From:   Hanjun Guo <guohanjun@...wei.com>
To:     "Abdulhamid, Harb" <harba@...eaurora.org>,
        Hanjun Guo <hanjun.guo@...aro.org>,
        Tyler Baicar <tbaicar@...eaurora.org>,
        <christoffer.dall@...aro.org>, <marc.zyngier@....com>,
        <pbonzini@...hat.com>, <rkrcmar@...hat.com>,
        <linux@...linux.org.uk>, <catalin.marinas@....com>,
        <will.deacon@....com>, <rjw@...ysocki.net>, <lenb@...nel.org>,
        <matt@...eblueprint.co.uk>, <robert.moore@...el.com>,
        <lv.zheng@...el.com>, <mark.rutland@....com>,
        <james.morse@....com>, <akpm@...ux-foundation.org>,
        <sandeepa.s.prabhu@...il.com>, <shijie.huang@....com>,
        <paul.gortmaker@...driver.com>, <tomasz.nowicki@...aro.org>,
        <fu.wei@...aro.org>, <rostedt@...dmis.org>, <bristot@...hat.com>,
        <linux-arm-kernel@...ts.infradead.org>,
        <kvmarm@...ts.cs.columbia.edu>, <Dkvm@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <linux-acpi@...r.kernel.org>,
        <linux-efi@...r.kernel.org>, <devel@...ica.org>
CC:     Naveen Kaje <nkaje@...eaurora.org>,
        "Jonathan (Zhixiong) Zhang" <zjzhang@...eaurora.org>
Subject: Re: [PATCH V3 05/10] acpi: apei: handle SEA notification type for
 ARMv8

Hi Harb,

On 2016/10/20 0:59, Abdulhamid, Harb wrote:
> On 10/18/2016 8:44 AM, Hanjun Guo wrote:
>> Hi Tyler,
>>
>> On 2016/10/8 5:31, Tyler Baicar wrote:
>>> ARM APEI extension proposal added SEA (Synchrounous External
>>> Abort) notification type for ARMv8.
>>> Add a new GHES error source handling function for SEA. If an error
>>> source's notification type is SEA, then this function can be registered
>>> into the SEA exception handler. That way GHES will parse and report
>>> SEA exceptions when they occur.
>> Does this SEA is replayed by the firmware (firmware first handling)
>> or directly triggered by the hardware when error is happened?
> Architecturally, an SEA must be synchronous and *precise*, so if you
> take an SEA on a particular load instruction, firmware/hardware should
> not be corrupting the context/state of the PE to allow software to
> determine which thread/process encountered the abort.  GHES error status

That's my concern too, and that's why I raised my question :)

> block will be expose to software with information about the type,
> severity, physical address impacted.
>
> Generally the error status block is populated by firmware.  However, as
> long as the above requirement is met, I don't think the spec precludes
> error status block being populated by hardware.  Those details must be
> completely transparent to software.
>
> Finally, to answer your more specific question:  If the implementation
> of firmware-first involves trapping the SEA in EL3 to do some firmware
> first handling, firmware must maintain the context of the offending ELx,
> generate an error record, and then "replay" the exception to normal
> (non-secure) software at the appropriate vector base address.
>

Thank you for your answer, it clears my confusion now, I will try something
similar on ARM64 platform, will get back to you if I get blocks.

Thanks
Hanjun