[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [XEN PATCH v2] xen: allow XSM_FLASK_POLICY only if checkpolicy binary is available


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Anthony PERARD <anthony.perard@xxxxxxxxxx>
  • Date: Mon, 19 Jul 2021 11:47:02 +0100
  • Authentication-results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Mon, 19 Jul 2021 10:47:16 +0000
  • Ironport-hdrordr: A9a23:+nmE6ajHXfTh7TgTfFR/vHJ3pnBQXh4ji2hC6mlwRA09TyX5ra 2TdZUgpHrJYVMqMk3I9uruBEDtex3hHP1OkOss1NWZPDUO0VHARO1fBOPZqAEIcBeOldK1u5 0AT0B/YueAd2STj6zBkXSF+wBL+qj6zEiq792usEuEVWtRGsVdB58SMHfiLqVxLjM2YqYRJd 6nyedsgSGvQngTZtTTPAh/YwCSz+e78q4PeHQ9dmca1DU=
  • Ironport-sdr: Nh3d0PwYnPJ/IoxcbBcl0hsP4P/Grmng47bky05K5cTS9U2jPjRwsqFaS3WxT5vwNA/PTBAJsf UgVeKCMb5vxgd7yrcWF62Wbkjoq2DjLyhbNKH8e7YSEQ8Px0YmatP5/kmiMKq1WMd30M+YNSSD msD6wRVzrLWiGyIlBM+yj1Z9k+Hqg13o/S1l/+LBDVAE14Dk3mh47PJiyrjsE7jnQD3quiM8cP fMUc1kiNCbUC8epW7vH4go/N/bksM7YujlfFIOMirGbDbmi/K3TSeRLyBoxffniJc2R3QZ+vBQ WtNkIhyFYvDtOGvKR4vXeqrs
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Mon, Jul 19, 2021 at 09:37:06AM +0200, Jan Beulich wrote:
> On 16.07.2021 14:38, Anthony PERARD wrote:
> > +export HAS_CHECKPOLICY := $(call success,$(CHECKPOLICY) -h 2>&1 | grep -q 
> > xen)
> 
> While the setting indeed gets obtained in a Makefile now, ...
> 
> > --- a/xen/common/Kconfig
> > +++ b/xen/common/Kconfig
> > @@ -235,8 +235,8 @@ config XSM_FLASK_AVC_STATS
> >  
> >  config XSM_FLASK_POLICY
> >     bool "Compile Xen with a built-in FLASK security policy"
> > -   default y if "$(XEN_HAS_CHECKPOLICY)" = "y"
> > -   depends on XSM_FLASK
> > +   default y
> > +   depends on XSM_FLASK && "$(HAS_CHECKPOLICY)"
> 
> ... it's still used as a Kconfig dependency. This in particular
> does not address George's concern about a setting silently getting
> turned off behind the back of the person having enabled it (and

This patch v2 wasn't meant to address George's concern which didn't
exist at the time this v2 was sent... I was trying to address yours.

But it seems that "George's concern" is part of your issues with
Kconfig too, which I missed when trying to right this v2.

Anyway, those two patches are the only way I'm going to try to fix the
random build failure in the GitLab CI, I'm not going to try to fix
issues with the use of Kconfig for now. In the mean time either v1 or v2
is committed, or will just keep getting random build failure in the
GitLab CI.

-- 
Anthony PERARD



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.