linux-kernel - RE: [vMCE design RFC] Xen vMCE design

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: <4FE82BE4020000780008B9E3@nat28.tlf.novell.com>
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/