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]

Date:	Fri, 22 Jun 2012 16:07:02 +0100
From:	"Jan Beulich" <JBeulich@...e.com>
To:	"Jinsong Liu" <jinsong.liu@...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>, "Tony Luck" <tony.luck@...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 15:46, "Liu, Jinsong" <jinsong.liu@...el.com> wrote:
> Jan Beulich wrote:
>> One other concern that occurred to me after long having sent
>> the original response: Your proposal aims at a fixed,
>> unmodifiable vMCE interface. How is that going to be forward
>> compatible? I.e. consider you had made that proposal before
>> the SRAO/SRAR changes went in - would the same interface (with
>> the same set of capability bits set/clear) still be suitable?
> 
> Yes, since it's pure s/w emulated interface. At the case when SRAO or SRAR 
> not supported by h/w platform, it's still OK, since under such case 
> hypervisor don't need deliver SRAO or SRAR to guest at all. The emulated vMCE 
> interface just tell the guest that it runs at a virtual platform with those 
> well-defined capabilities.

I probably didn't express well enough what I want you to check:
Consider you had done the current re-design work without
SRAO/SRAR in mind (e.g. a couple of years ago). Would the
end result have been the same? Namely, would the bits you
nominate to be set/clear in MCG_CAP be the same?

>> I think that we minimally need to retain the MCG_CAP register
>> as being of potentially variable content (and hence needing
>> saving/restoring on migration). To support this in a forward
>> compatible manner, we may have to have a way to tell the
>> hypervisor e.g. via command line option which extra MSRs
>> have to be treated read-as-zero/writes-ignored upon guest
>> accesses.
> 
> Seems unnecessary, reason as above.

So going forward you see no possibility of additions to the
interface that might warrant allowing more bits to be set in
MCG_CAP than you define to be set here? That really looks
unrealistic to me.

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/