From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH v3 3/3] tools: introduce parameter max_wp_ram_ranges. Date: Tue, 2 Feb 2016 11:31:52 +0000 Message-ID: <56B093A8.6020209@citrix.com> References: <1454064314-7799-1-git-send-email-yu.c.zhang@linux.intel.com> <1454064314-7799-4-git-send-email-yu.c.zhang@linux.intel.com> <56ABA26C02000078000CC7CD@prv-mh.provo.novell.com> <56ACCAD5.8030503@linux.intel.com> <56AF1CE302000078000CCBBD@prv-mh.provo.novell.com> <20160201120244.GT25660@citrix.com> <56AF5A6402000078000CCEB2@prv-mh.provo.novell.com> <20160201124959.GX25660@citrix.com> <56AF669F02000078000CCF8D@prv-mh.provo.novell.com> <56AF7657.1000200@linux.intel.com> <56AF85A3.6010803@linux.intel.com> <56AF977602000078000CD1BE@prv-mh.provo.novell.com> <56AF89BA.4060105@linux.intel.com> <22191.36960.564997.621538@mariner.uk.xensource.com> <56B093B802000078000CD5FE@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <56B093B802000078000CD5FE@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , Ian Jackson Cc: kevin.tian@intel.com, wei.liu2@citrix.com, ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com, xen-devel@lists.xen.org, Paul.Durrant@citrix.com, Zhang Yu , zhiyuan.lv@intel.com, keir@xen.org List-Id: xen-devel@lists.xenproject.org On 02/02/16 10:32, Jan Beulich wrote: >>>> On 01.02.16 at 18:05, wrote: >> Having said that, if the hypervisor maintainers are happy with a >> situation where this value is configured explicitly, and the >> configurations where a non-default value is required is expected to be >> rare, then I guess we can live with it. > Well, from the very beginning I have been not very happy with > the introduction of this, and I still consider it half way acceptable > only because of not seeing any good alternative. If we look at > it strictly, it's in violation of the rule we set forth after XSA-77: > No introduction of new code making the system susceptible to > bad (malicious) tool stack behavior Lets take a step back here. If your toolstack is malicious, you have already lost. Coding Xen around this is a waste of time. The XSM case is for splitting out some of the privileged domains responsibilities to less privileged domains. In these cases, we do indeed want to assure that the somewhat-privileged entity cannot abuse anything outside its area of privilege. This specific issue concerns resource allocation during domain building and is an area which can never ever be given to a less privileged entity. ~Andrew