Re: [Xen-devel] [PATCH 3/8] xen: defer call to xen_restrict until after os_setup_post

[Anthony PERARD <anthony.perard@xxxxxxxxxx>]

On Mon, Oct 09, 2017 at 05:58:17PM +0100, Ian Jackson wrote:
> (My resend has crossed with your review.  Sorry about that.)
> 
> Anthony PERARD writes ("Re: [PATCH 3/8] xen: defer call to xen_restrict until 
> after os_setup_post"):
> > On Wed, Oct 04, 2017 at 05:18:06PM +0100, Ian Jackson wrote:
> 
> > > +void xen_setup_post(void)
> > > +{
> > > +    int rc;
> > 
> > We probably want to check here if Xen is enable (via xen_enabled()).
> > xen_domid_restrict could be true when Xen is not used, even if it does
> > not make sense to use -xen-domid-restrict in that case.
> 
> Should -xen-domid-restrict without xen_enabled() not fail ?  IMO it is
> normally better for an option which requests enhanced security to fail
> when it can't do its job, rather than just hoping that its
> inapplicability is intentional.

I'm tring to find out what does calling xen_restrict_all(0), when
running an non-Xen guest. I think it would just lock(), then unlock()
then there should not be any handle to restrict, and return 0; is that
right?

So I think the code is fine like this. I'll put my Reviewed-by to the
last version.

Thanks.

> OTOH I suppose there is an argument that without xen_enabled() the
> function of -xen-domid-restrict is achieved, in that without
> xen_enabled() qemu is unable (after dropping privileges) to act on
> Xen domains at all...
> 
> Thanks,
> Ian.

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel