[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: Mon, 21 Jun 2021 11:41:21 +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=+7Z5rl6BOUJjVox1tz9DXVUzFGaNOceGaxqhCmktjwo=; b=COveSTiUm9FoeZYhOeC6a+ODdWa/1wd7juqbTlTwEgtY1yUkZba11XeIDPxB0aJARohpdBkR9nlpKaPTubiYNcOYxKCPbcNFCHzLzJBfhHC8UNDroVqghjQrdJLLf7xWyrdWbx7TZLdaOPtJAHd1VgpvJoIYPol9+lhAWQoGnEHeS7M45HQB/BL7yVv+6IonWn5v6Dl84ModbHidFEH10K9lUAMX5TRc3HPeEyitznkYQqJL2Yj72hJucwiT1tpRaAFarlXmjXfdpLTJRgmQdd//rSoPoLz3zA1IHOJLg+TDopa+Wjzque1xOWbWPvEwobLrM2CTW5fLx/jWuE0PCQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=k6b7JYa5Jid1qJypnSIxNbwRfruvafmiRvRrf8PUx7WsGCNwC4oRDWQUTUHqic+2NX49pSLEcoCrTj+zBgrCBOLopPlVNBG5ECB8DnTnSNAkhhDaGzti15Swqoo+3bgq/XzdcR9v9VsICGzRzg3ZovxR1yOHI24XnkfFhL82gSM/c7QQvGtvcNCYaud6+PTxJdwQa2j3DD2AktcGYnf+TGGro9PdNx2O8MCX/m25SJZd3btZ4IU+wUqRs3x5k/np4jexZaJrX+3oPOpDzBI6BpjUFmrTTB+75b4ZKqw91IpmUT1jFXZRkFJRL/HGyNHjaK5rFNj2bcmM8IN3qUKqnA==
  • Authentication-results: esa5.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: Mon, 21 Jun 2021 10:41:51 +0000
  • Ironport-hdrordr: A9a23:RvDLvqzNJm1f34sftuVSKrPxteskLtp133Aq2lEZdPULSKOlfp 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: EVhOul9vqS7YydjoHpMySQj1q+SXI2rH8C5D4sMBQtdSJlIbp8l1kroNLCssRKAg+sQnUy2cvk PB6xruCqxEszK18RO1dZ3Jp552zr/hFYMO3h20vicN1j3iYwmK/Z6pJPk452XCNN7O/RpMxFPU itgVIMTl3x4tirI8+69jAQGp3gr9w0oy92uS3sGx4XrI1AH/52SlVpD+dG/Kxbu0/knzDCfFD/ 8grew3tk4npIv+dhiBcEMESQDGxu8dCuv8l/kyLR4o5MMca1SRuXcIAmqUO2nchcK1ZusLbo3+ f3s=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 21/06/2021 07:58, Jan Beulich wrote:
> On 18.06.2021 22:27, Daniel P. Smith wrote:
>> On 6/18/21 8:26 AM, Jan Beulich wrote:
>>> On 18.06.2021 01:39, Daniel P. Smith wrote:
>>>> The only difference between !CONFIG_XSM and CONFIG_XSM with 
>>>> 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.
>> Apologies that I did not express this clearly. What I was attempting to
>> say is the fact of the matter is that there is no logical behavior
>> difference between "XSM no" and "XSM yes with dummy policy". The only
>> difference is the mechanics of how the dummy functions get called.
>> Specifically via macro magic the dummy functions are either flipped into
>> static inline declarations that are then included into the code where
>> they are invoked or the macro magic has them ending up in the dummy.c
>> XSM module where they are wrapped in macro generated functions that are
>> set as the functions in the dummy xsm_ops structure. Thus it is always
>> the same logic being invoked, it is just mechanics of how you get to the
>> logic.
> That's what I understood, really. What I dislike is the inline functions
> going away in what we currently call !XSM.

I'm sorry, but this is an unreasonable objection.

The mess used to create the status quo *is* the majority reason why
fixing/developing XSM is so hard, and why the code is so obfuscated.  To
prove this point, how many people on this email thread realise that
calls using XSM_HOOK offer 0 security under xsm_default_action()?

Having xsm_default_action() forced inline isn't obviously the right move
in the first place, and I doubt that you could even measure a
performance difference for using real function calls.

Even if there is a marginal performance difference, and I doubt that
there is, performance is far less important than de-obfuscating the code
and fixing our various security mechanisms to be first-class supported




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