[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: George Dunlap <George.Dunlap@xxxxxxxxxx>
  • Date: Mon, 19 Jul 2021 14:33:09 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PwfhRq6Q7A8bPn0ceDbsHhKD9+jbdK1swWXsSjpd16U=; b=JtbXUF6BognArB4fB99STtAoIfhPO+hOBfrXGjqf+wRCmudHehiFtAlU9/xOip4QPq8MJEtV8y3qXhfhMQ3+CazhHVFJej/5y+B3Gfh8AN3EVvOUkE55AFp8SnWsaxUvaHERqpRqTu8rBA3u2CCkC6HdoEg47xjI4wuDGnSxujj0Y8oaH64bfoma2kzm9nSP+HxJhVLNK4YGdSBt0IVAwB9gryheCXoV31irlleXli6j6ScafEpyaSxm2S5hljTpjscXnhsohNEUfIwYqX4yaPifglgLK2I5T0W6G/mfMg56UmKsYFv/CvEBuAn08n+0WJ7OQs6VvM/JYiPfMxtWLQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=As7sXRFKxvqhVJYp+bYt037SCzz65UsNZBbeclx6t3MKPR3vJpuOEdT8eR+XolkKaB2a9ChE8FyZr0VJ7LYZhT0x1ODympSqt3HABuST186WWT9i+Ditx0TC1kJNnFI4u1ubZJ5C+v8ndEYwR0auLNyuFGJTx036CbP4E4UPu0NPI5aVs4bQ6Q/4sBi+/YSENAGzcJl2TH2kMDDMXhr7iq8iwjvWylMMbSXT6JeaqpCo8HKSrcz4lj9th764NAqEM5u9uG1Fp90xotqH7z5lW0CywR1kfmg0Zecb6nigXeN03+0V6046wjC+PUlq/escLZ3qVtQcSFrYI1MiUjP6LQ==
  • Authentication-results: esa2.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: Anthony Perard <anthony.perard@xxxxxxxxxx>, Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Mon, 19 Jul 2021 14:33:33 +0000
  • Ironport-hdrordr: A9a23:ovyuJqFFdUSvl2uMpLqEHseALOsnbusQ8zAXPiBKJCC9vPb5qy nOpoV86faQslwssR4b9uxoVJPvfZqYz+8W3WBzB8bEYOCFghrKEGgK1+KLrwEIWReOk9K1vZ 0KT0EUMqyVMbEVt6fHCAnTKade/DGEmprY+9s3GR1WPHBXg6IL1XYINu6CeHcGPTWvnfACZe ehDswsnUvZRV0nKv6VK1MiROb5q9jChPvdEGI7705O0nj0sduwgoSKaSSl4g==
  • Ironport-sdr: SSpEXkjkqDLmZYXkxHWsXbGJHyVds+JN2cEfI1XHJ7cJmkczMx+Sap/j4Vytb/kKIEilGoPAZg 4yl+1nQjcTGdgP2P+7ilsXDQU6DIZffOUoPoe/oYfromULIVh4h8xThoKkyqMviMFrDQi4Kv1G MVao61Ql7/XdyLSb4N/aalrsqPVq3Llt+EB666dpilzcMyjBOobm482GjDpcHTfJkwKr2KaEXr frG4e42nMNiu51v4pai26ARb3V4SBl+H1nh0IOSpE/vPR+yaXu4M38nz0SALyXheryxBC9RQ7V IWwLIy6eiIP8o/kuTk+Xj+/c
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHXej93TtKmWup1Y0m/GZbcx8POPatJ7UAAgAA1EQCAAAT5AIAAOjKA
  • Thread-topic: [XEN PATCH v2] xen: allow XSM_FLASK_POLICY only if checkpolicy binary is available

On 19 Jul 2021, at 12:04, Jan Beulich <jbeulich@xxxxxxxx> wrote:

On 19.07.2021 12:47, Anthony PERARD wrote:
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

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.

Fair enough. I actually think that randconfig shouldn't act quite as
randomly as it does.

It sounds like randconfig currently works appropriately for how KConfig is meant to work.  That is, for good or for ill, KConfig seems designed to silently discard options with missing dependencies (either internal or external); so generating a config with missing dependencies to hand to it is “sensible”.

But what's sensible as behavior there really
depends heavily on the future intentions with .config. If we follow
Linux'es model (which Andrew advocates for), its randomness would be
limited by options which could get randomly set getting further
altered by environmental conditions. Hence that would limit what can
actually be tested, but it would avoid failures resulting from the
environment not matching the chose settings.

Otoh with our current model (largely, leaving aside the few
environment checks we've already got) what is being asked for is
what is going to get built. But failure from environmental
constraints shouldn't be treated the same as failure from bad
interaction of options; it's (aiui) the latter which randconfig is
supposed to point out.

Right; so another solution to the ‘randconfig CI loop’ issue would be to have the pipeline pass (or some non-pass non-fail state if possible) when then build failed because there were missing dependencies.  Maybe one way of doing that would be to have a “make check-dependencies” target that would run first.

That said, since it’s basically known that “silently disabling things it can’t build" is a quirk of Kconfig, I’m less inclined to object to v1 of the patch.




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