linux-kernel - Re: [PATCH V11 10/10] arm/arm64: KVM: add guest SEA support

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:   Mon, 6 Mar 2017 11:38:46 +0800
From:   Xiongfeng Wang <wangxiongfeng2@...wei.com>
To:     Marc Zyngier <marc.zyngier@....com>,
        James Morse <james.morse@....com>
CC:     <mark.rutland@....com>, <linux-efi@...r.kernel.org>,
        <kvm@...r.kernel.org>, <rkrcmar@...hat.com>,
        <matt@...eblueprint.co.uk>, <catalin.marinas@....com>,
        Tyler Baicar <tbaicar@...eaurora.org>, <will.deacon@....com>,
        <linux@...linux.org.uk>, <paul.gortmaker@...driver.com>,
        <lv.zheng@...el.com>, <kvmarm@...ts.cs.columbia.edu>,
        <fu.wei@...aro.org>, <tn@...ihalf.com>, <zjzhang@...eaurora.org>,
        <robert.moore@...el.com>, <linux-acpi@...r.kernel.org>,
        <eun.taik.lee@...sung.com>, <shijie.huang@....com>,
        <labbott@...hat.com>, <lenb@...nel.org>, <harba@...eaurora.org>,
        <john.garry@...wei.com>, <Suzuki.Poulose@....com>,
        <punit.agrawal@....com>, <rostedt@...dmis.org>,
        <nkaje@...eaurora.org>, <sandeepa.s.prabhu@...il.com>,
        <linux-arm-kernel@...ts.infradead.org>, <devel@...ica.org>,
        <rjw@...ysocki.net>, <rruigrok@...eaurora.org>,
        <linux-kernel@...r.kernel.org>, <astone@...hat.com>,
        <hanjun.guo@...aro.org>, <joe@...ches.com>, <pbonzini@...hat.com>,
        <akpm@...ux-foundation.org>, <bristot@...hat.com>,
        <christoffer.dall@...aro.org>, <shiju.jose@...wei.com>
Subject: Re: [PATCH V11 10/10] arm/arm64: KVM: add guest SEA support

Hi Marc,

On 2017/3/2 17:39, Marc Zyngier wrote:
> On 01/03/17 02:31, Xiongfeng Wang wrote:
> 
> [lot of things]
> 
>> If an SEA is injected into guest OS, the guest OS will jump to the SEA
>> exception entry when the context switched to guest OS. And the CPSR and
>> FAR_EL1 are recovered according to the content of vcpu. Then the guest
>> OS can signal a process or panic. If another guest process read the
>> error data, another SEA will be generated and it will be single too.
>>
>> Without QEMU involved, the drawback is that no APEI table can be mocked
>> up in guest OS, and no memory_failure() will be called. So the memory of
>> error data will be released into buddy system and assigned to another
>> process. If the error was caused by instantaneous radiation or
>> electromagnetic, the memory is usable again if it is written with a
>> correct data. If the memory has wore out and a correct data is written,
>> the ECC error may occurs again with high possibility. Before a 2-bit ECC
>> error is reported, much more 1-bit errors will be reported. This is
>> report to host os, the host os can determine the memory node has worn
>> out and hot-plug out the memory node, and guest os may be terminated if
>> its memory data can't be migrated.
>>
>> Of course, it is better to get QEMU involved, so the memory_failure can
>> be executed in guest OS. But before that implemented, can we add SEA
>> injection in kvm_handle_guest_abort()?
> 
> No. I will strongly object to that. This is a platform decision to
> forward SEAs, not an architectural one. The core KVM code is only
> concerned about implementing the ARM architecture, and not something
> that is firmware dependent.
> 
Thanks for the reply!
I'm not sure if there exists some misunderstanding here. I was saying
that APEI stuff is not included in the core KVM code, but SEA injection
can be included, just like the SEI injection in the core KVM code. Yes,
APEI is firmware dependent, but I think SEA is not. And the processing
for SEA doesn't depend on whether APEI is implemented.


Thanks,

Wang Xiongfeng
.