From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: XSM: new set of "avc denied" Date: Tue, 26 May 2015 10:13:31 +0100 Message-ID: <1432631611.14664.71.camel@citrix.com> References: <20150525094032.GV19083@zion.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YxAwL-0005nD-60 for xen-devel@lists.xenproject.org; Tue, 26 May 2015 09:14:25 +0000 In-Reply-To: <20150525094032.GV19083@zion.uk.xensource.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: Wei Liu Cc: xen-devel@lists.xenproject.org, Daniel De Graaf List-Id: xen-devel@lists.xenproject.org On Mon, 2015-05-25 at 10:40 +0100, Wei Liu wrote: > I had a look at Osstest's latest xen-unstable run [0]. With Ian's patch > series we finally passed the point of guest creation on x86. > > We now have a new set of "avc denied". Thanks for picking up on these, I was just about to. > May 24 20:18:05.945118 (XEN) avc: denied { get_vnumainfo } for domid=1 scontext=system_u:system_r:domU_t tcontext=system_u:system_r:domU_t_self tclass=domain2 > > This is HVM loader trying to call get_vnumainfo > > May 24 20:28:50.593013 (XEN) avc: denied { logdirty } for domid=0 target=3 scontext=system_u:system_r:dom0_t tcontext=system_u:system_r:domU_t tclass=shadow > May 24 20:29:20.721085 (XEN) avc: denied { disable } for domid=0 target=3 scontext=system_u:system_r:dom0_t tcontext=system_u:system_r:domU_t tclass=shadow > May 24 20:29:20.737023 (XEN) avc: denied { disable } for domid=0 target=3 scontext=system_u:system_r:dom0_t tcontext=system_u:system_r:domU_t tclass=shadow > > The above failures made guest local migration test fail for both PV and HVM > guests. Yes, this seems to be the biggest cause of failures > May 24 14:36:47.541016 (XEN) avc: denied { writeconsole } for domid=1 scontext=system_u:system_r:domU_t tcontext=system_u:system_r:xen_t tclass=xen > > This is PV specific, I think it was due to PV guest was configured to write to > console and XSM (rightfully?) rejected that. I think this is from the use of xen_raw_console_write early on in the Linux pvops kernel. By default these would be nop on a debug=n hypervisor, and they are controllable with the guest_loglvl hypervisor option in both debug cases, I think. I think XSM rejecting is valid, but I'd also be happy with a change to allow it and rely on the handling via the console options as folks like. Ian. > My guess is that HVM is not > configured to write to console so I don't see that in HVM test cases. Correct, although I would expect hvmloader to have been even more chatty, guess I am wrong about that. FWIW I saw quite a few of these from the stubdom mini-os when I tested stub-dm as well. Ian.