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
| ||
|
Date: Mon, 25 Jun 2012 08:14:12 +0100 From: "Jan Beulich" <JBeulich@...e.com> To: "Jinsong Liu" <jinsong.liu@...el.com>, "Tony Luck" <tony.luck@...el.com> Cc: "Ashok Raj" <ashok.raj@...el.com>, "Donald D Dugger" <donald.d.dugger@...el.com>, "Haitao Shan" <haitao.shan@...el.com>, "Jun Nakajima" <jun.nakajima@...el.com>, "Susie Li" <susie.li@...el.com>, "Will Auld" <will.auld@...el.com>, "Xiantao Zhang" <xiantao.zhang@...el.com>, "Yunhong Jiang" <yunhong.jiang@...el.com>, "xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "Keir Fraser" <keir@....org> Subject: RE: [vMCE design RFC] Xen vMCE design >>> On 22.06.12 at 18:21, "Luck, Tony" <tony.luck@...el.com> wrote: > There may be some secondary side benefit that independent errors might be > reported to different banks, and so avoid some overwrite problems. But I > don't > think that Xen has a big worry with overwrite, does it? In general the > errors that > you will show to the guest are ones that you expect the guest to handle > immediately > (e.g. SRAO and SRAR signaled with a machine check). You do not log any > corrected > errors to the guest (they can't do anything useful with them). You certainly > don't > log any errors that are not signaled. So you should never have any errors > hanging > around in banks for long periods that would get overwritten. The problem is the determination of what "long" means here. The target vCPU may not get scheduled for extended periods of time (raising its priority would have other undesirable implications), so the risk over overwrite exists from that perspective. However, assuming that reportable errors get associated with a particular vCPU, and that such a vCPU won't be able to execute any further guest code prior to the delivery of the exception, the only real risk here would be if the vMCE handler itself raised another event. That I agree with Jinsong can be well treated as fatal (killing the guest, provided the event gets properly logged so the admin isn't left in the dark regarding the unexpected death of the VM), mostly matching would a single bank hardware implementation would result in. Jan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists