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

Re: [PATCH 3/6] xsm: enabling xsm to always be included


  • To: Jan Beulich <jbeulich@xxxxxxxx>, "Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Fri, 18 Jun 2021 22:20:10 +0100
  • 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=U/oTuQZ2LTig2J7h9rI2ap5PGwt1R20OK25TxbnMrp0=; b=hyaZ5d6FrzDp6Nii2qcbGCqrIJYZlqvC+E4AKeHfU+7XiV/KyWMoJ0bF6ZoSB8TCkiLUomDhPiNH9BrfrLX06xEwVygrSB+HMNsbMmudTwk61eqTpLCyZMxyp69Xp3ZCJDq+kO6mPDRBTNDGEKswDsmcztE4Mny3pvaDQ3UUzMloLGASg7plPtJyONrVddm/TcD1XuV6A5OsAS+ryvpSbXxvwz4N5yKKZJZeqwnrKztbQErfw0TD0bFcJJ5ah2DpNDjJYDn2WRa2a27frsM2/wMp0UyJL4KRNwmziwTx3sSnxHcfr3Cu4vtwbNJ7jHsVd3lzpxiAc/LTL3AWfYBZhw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=irf/RhW85TI0KZjdqkFwCKEOwDOJ5pzyjeQDGvsR41ZocYE6/SZaOU1AGcUi1FEoMf5nLOltf79EXQRSsLn+HdQ19/91yVaXeJJ1tXGrFBMhuoH0BsHzXQpiLpDfovcqFVd20KkoY6pRIQybeGrxXuaPyM8/T+kVuxfiOgUs5OR8cm0vNGIiOmq+Dsz1o24sEFrsS+mS5SeVZN7Dn6R8QIoahiZ/3eHLtm1OmkGicpTs7kcyIJUFqNdlSRBV0cc1rU3F6SH2Wy39s9lCmELd1AswkhtXg3v1XUo8VwQrWxaJFcqllpYHm8zo3r8vM4n3aPNfIgblxb9GyJR0GoFZmA==
  • Authentication-results: esa3.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Tamas K Lengyel <tamas@xxxxxxxxxxxxx>, Tim Deegan <tim@xxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, Alexandru Isaila <aisaila@xxxxxxxxxxxxxxx>, Petre Pircalabu <ppircalabu@xxxxxxxxxxxxxxx>, Dario Faggioli <dfaggioli@xxxxxxxx>, Paul Durrant <paul@xxxxxxx>, Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>, <persaur@xxxxxxxxx>, <christopher.w.clark@xxxxxxxxx>, <adam.schwalm@xxxxxxxxxx>, <scott.davis@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Fri, 18 Jun 2021 21:20:42 +0000
  • Ironport-hdrordr: A9a23:VlQ8X6xO97x3xys/F4uxKrPxteskLtp133Aq2lEZdPULSKOlfp GV8MjziyWYtN9wYhAdcdDpAtjkfZquz+8L3WB3B8bfYOCGghrUEGgG1+XfKlLbalXDH4JmpM Bdmu1FeafN5DtB/LXHCWuDYq8dKbC8mcjC74eurAYZcegpUdAF0+4QMHfqLqQcfnghOXNWLu v/2iMKnUvaRZxBBf7Ld0XtEtKz6eEi0/ndEFc7Li9izDPLoSKj6bb8HRTd9hACUwlXybNn1W TeiQT26oiqrvn+k3bnpi/uxqUTvOGk5spIBcSKhMRQAjLwijywbIAkf7GZpjg6rMym9V5vut jRpBULOdh19hrqDyCIiCqo/zOl/Ccl6nfkx1Pdq2Dku9bFSDUzDNcErZ5FczPCgnBQ+e1U4e Zu5Sa0ppBXBRTPkGDW/N7TTSxnkUKyvD4LjfMTtXpCSoETAYUh77D3xHklV6voIRiKrrzOSI JVfZjhDbdtABCnhknizy1SKIfGZAVqIv/uKXJyyPB80FBt7T1EJgUjtZcidtppzuN0d3B+3Z WyDk1frsAFciYnV9MIOA4/e7rANoXse2OBDIvAGyWpKEk4U0i94KIft49Fmt1CPqZ4lqcPpA ==
  • Ironport-sdr: b+ETk2dl0f5Ytp4jv7vGIZLl2GUd+XuQXhxgNn7NR8bCbv0UqO8z3mldOXFCJcWxC54WEHteB0 En0H1f0n0qU6LcvMk+wbZ/qWWdy9LktvbaV/T6L3eJ4JlPXJTJEUbG4SHaYBEfBsSlLP2jN0AX c1392C5WCcAY2H2PIEFvQasM+7uNrX0ciHwn+Ad/ptmTjheu3/TSwzt75tSeavb5L3fk6bRCJb rgiXVYxjOKRCuCiUlueh0jAqC7XO2cKz8Ger4xiRqKzl80I1RnwarWWeNRUTotGelYZ83zMh29 Ov4=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 18/06/2021 13:26, Jan Beulich wrote:
> On 18.06.2021 01:39, Daniel P. Smith wrote:
>> The only difference between !CONFIG_XSM and CONFIG_XSM with !CONFIG_XSM_SILO 
>> and !CONFIG_XSM_FLASK
>> is whether the XSM hooks in dummy.h are called as static inline functions or 
>> as function
>> pointers to static functions. As such this commit,
>>  * eliminates CONFIG_XSM
> Following from what Andrew has said (including him mentioning your
> changing of certain Kconfig option defaults), I'm not convinced this is
> a good move. This still ought to serve as the overall XSM-yes-or-no
> setting. If internally you make said two variants match in behavior,
> that's a different thing.

I firmly disagree. There is no such thing as !XSM even in staging right now.

All over Xen, we have calls to xsm_*() functions which, even in the !XSM
case, contain a non-trivial security policy.

The fact that under the hood, XSM vs !XSM creates two very different
implementations of "the dom0-all-powerful model" is an error needing
correcting, as it contributes a massive quantity of code complexity.

This series of Daniel's takes steps to make the code match reality, and
getting rid of CONFIG_XSM is absolutely the right thing to do.  XSM is
never actually absent from a build of Xen, even if you choose CONFIG_XSM=n.


I do think that the thing we currently call XSM_DUMMY wants renaming to
indicate that it is "the dom0-all-powerful" security model, and I think
that wants doing as part of this series.  Name suggestions welcome.

~Andrew




 


Rackspace

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