From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [PATCH v1] Add build-id to XENVER hypercall. Date: Fri, 9 Oct 2015 09:25:42 -0400 Message-ID: <20151009132542.GH4709@l.oracle.com> References: <1444359390-14153-1-git-send-email-konrad.wilk@oracle.com> <5617943C02000078000A99B8@prv-mh.provo.novell.com> <5617AFEE.4090908@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZkXgK-00018f-HY for xen-devel@lists.xenproject.org; Fri, 09 Oct 2015 13:25:56 +0000 Content-Disposition: inline In-Reply-To: <5617AFEE.4090908@citrix.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: Andrew Cooper Cc: wei.liu2@citrix.com, ian.campbell@citrix.com, ian.jackson@eu.citrix.com, mpohlack@amazon.de, Jan Beulich , xen-devel@lists.xenproject.org, dgdegra@tycho.nsa.gov List-Id: xen-devel@lists.xenproject.org On Fri, Oct 09, 2015 at 01:15:42PM +0100, Andrew Cooper wrote: > On 09/10/15 09:17, Jan Beulich wrote: > >>>> On 09.10.15 at 04:56, wrote: > >> However they also change the behavior of the existing hypercall > >> for XENVER_[compile_info|changeset|commandline] and make them > >> dom0 accessible. This is if XSM is built in or not (though with > >> XSM one can expose it to a guest if desired). > > Wasn't the outcome of the previous discussion that we should not > > alter default behavior for existing sub-ops? > > I raised a worry that some guests might break if they suddenly have > access to this information cut off. Let me double-confirm that the guests are OK with this being gone. I did ran tests to see if the worked, but hadn't actually tried acessing (/sys/hypervisor/xen*) the values. > > > And even if I'm > > misremembering, I can see reasons for not exposing the command > > line, but what value has not exposing compile info and changeset > > again? > > There is a fear that providing such information makes it easier for > attackers who have an exploit for a specific binary. > > > The more that the tool stack uses the two, and as we know > > tool stacks or parts thereof can live in unprivileged domains. > > I would argue than a fully unprivileged toolstack domain has no need for > any information from this hypercall. It it needs some privilege, then > XSM is in use and it can be given access. What he said :-) > > > Plus > > there is also a (hg-centric and hence generally broken) attempt to > > store it in hvm_save(). > > I will be addressing this in due course with my further cpuid plans. > > ~Andrew