linux-kernel - Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS

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]

Message-ID: <CAFEAcA9O_mUbO=RChLwpj=qr0ZDg6iEsYwzWLTbHMRV-9z-1vQ@mail.gmail.com>
Date:   Tue, 28 Mar 2017 12:33:59 +0100
From:   Peter Maydell <peter.maydell@...aro.org>
To:     Christoffer Dall <cdall@...aro.org>
Cc:     James Morse <james.morse@....com>, Leif.Lindholm@...aro.com,
        kvm-devel <kvm@...r.kernel.org>,
        Marc Zyngier <marc.zyngier@....com>,
        Catalin Marinas <catalin.marinas@....com>,
        Achin Gupta <Achin.Gupta@....com>,
        Will Deacon <will.deacon@....com>,
        lkml - Kernel Mailing List <linux-kernel@...r.kernel.org>,
        gengdongjiu <gengdongjiu@...wei.com>, wangxiongfeng2@...wei.com,
        wuquanming@...wei.com, huangshaoyu@...wei.com,
        arm-mail-list <linux-arm-kernel@...ts.infradead.org>,
        Andre Przywara <andre.przywara@....com>,
        "kvmarm@...ts.cs.columbia.edu" <kvmarm@...ts.cs.columbia.edu>
Subject: Re: [PATCH] kvm: pass the virtual SEI syndrome to guest OS

On 28 March 2017 at 12:23, Christoffer Dall <cdall@...aro.org> wrote:
> On Tue, Mar 28, 2017 at 11:48:08AM +0100, James Morse wrote:
>> On the host, part of UEFI is involved to generate the CPER records.
>> In a guest?, I don't know.
>> Qemu could generate the records, or drive some other component to do it.
>
> I think I am beginning to understand this a bit.  Since the guet UEFI
> instance is specifically built for the machine it runs on, QEMU's virt
> machine in this case, they could simply agree (by some contract) to
> place the records at some specific location in memory, and if the guest
> kernel asks its guest UEFI for that location, things should just work by
> having logic in QEMU to process error reports and populate guest memory.

Is "write direct to guest memory" the best ABI here or would
it be preferable to use the fw_cfg interface for the guest UEFI
to retrieve the data items on demand?

Is there a pre-existing "this is how it works on x86" implementation?

thanks
-- PMM