All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: "Daniel P. Smith" <dpsmith@apertussolutions.com>,
	<xen-devel@lists.xenproject.org>
Cc: "Stefano Stabellini" <sstabellini@kernel.org>,
	"Julien Grall" <julien@xen.org>,
	"Volodymyr Babchuk" <Volodymyr_Babchuk@epam.com>,
	"George Dunlap" <george.dunlap@citrix.com>,
	"Ian Jackson" <iwj@xenproject.org>,
	"Jan Beulich" <jbeulich@suse.com>, "Wei Liu" <wl@xen.org>,
	"Roger Pau Monné" <roger.pau@citrix.com>,
	"Tamas K Lengyel" <tamas@tklengyel.com>,
	"Tim Deegan" <tim@xen.org>, "Juergen Gross" <jgross@suse.com>,
	"Alexandru Isaila" <aisaila@bitdefender.com>,
	"Petre Pircalabu" <ppircalabu@bitdefender.com>,
	"Dario Faggioli" <dfaggioli@suse.com>,
	"Paul Durrant" <paul@xen.org>,
	"Daniel De Graaf" <dgdegra@tycho.nsa.gov>,
	persaur@gmail.com, christopher.w.clark@gmail.com,
	adam.schwalm@starlab.io, scott.davis@starlab.io
Subject: Re: [PATCH 1/6] xsm: refactor xsm_ops handling
Date: Fri, 18 Jun 2021 12:34:54 +0100	[thread overview]
Message-ID: <07566583-d4bc-dfb8-eccd-d779783d959a@citrix.com> (raw)
In-Reply-To: <20210617233918.10095-2-dpsmith@apertussolutions.com>

On 18/06/2021 00:39, Daniel P. Smith wrote:
> The assignment and setup of xsm_ops structure was refactored to make it a
> one-time assignment. The calling of the xsm_ops were refactored to use the
> alternate_call framework to reduce the need for retpolines.
>
> Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>

I think the commit message needs a little more explanation for anyone
doing code archaeology.

AFAICT, the current infrastructure has some (incomplete?) support for
Flask to unload itself as the security engine, which doesn't sounds like
a clever thing in general.

What we do here is make a semantic change to say that the security
engine (Dummy, Flask or SILO) gets chosen once during boot, and is
immutable thereafter.  This is better from a security standpoint (no
accidentally unloading Flask at runtime), and allows for the use of the
alternative_vcall() infrastructure to drop all the function pointer calls.

Does that about sum things up?

> diff --git a/xen/xsm/flask/flask_op.c b/xen/xsm/flask/flask_op.c
> index 01e52138a1..df9fcc1d6d 100644
> --- a/xen/xsm/flask/flask_op.c
> +++ b/xen/xsm/flask/flask_op.c
> @@ -225,26 +225,7 @@ static int flask_security_sid(struct xen_flask_sid_context *arg)
>  
>  static int flask_disable(void)
>  {
> -    static int flask_disabled = 0;
> -
> -    if ( ss_initialized )
> -    {
> -        /* Not permitted after initial policy load. */
> -        return -EINVAL;
> -    }
> -
> -    if ( flask_disabled )
> -    {
> -        /* Only do this once. */
> -        return -EINVAL;
> -    }
> -
> -    printk("Flask:  Disabled at runtime.\n");
> -
> -    flask_disabled = 1;
> -
> -    /* Reset xsm_ops to the original module. */
> -    xsm_ops = &dummy_xsm_ops;
> +    printk("Flask:  Disabling is not supported.\n");

Judging by this, should this patch be split up more?

I think you want to remove FLASK_DISABLE (and this function too - just
return -EOPNOTSUPP in the parent) as a separate explained change (as it
is a logical change in how Flask works).

The second patch wants to be the rest, which changes the indirection of
xsm_ops and converts to vcall().  This is a fairly mechanical change
without semantic changes.

I'm unsure if you want a 3rd patch in the middle, separating the
xsm_core_init() juggling, with the "switch to using vcall()".  It might
be a good idea for more easily demonstrating the changes, but I'll leave
it to your judgement.

> diff --git a/xen/xsm/xsm_core.c b/xen/xsm/xsm_core.c
> index 5eab21e1b1..acc1af7166 100644
> --- a/xen/xsm/xsm_core.c
> +++ b/xen/xsm/xsm_core.c
>  static int __init xsm_core_init(const void *policy_buffer, size_t policy_size)
>  {
>  #ifdef CONFIG_XSM_FLASK_POLICY
> @@ -87,17 +86,22 @@ static int __init xsm_core_init(const void *policy_buffer, size_t policy_size)
>      }
>  #endif
>  
> -    if ( verify(&dummy_xsm_ops) )
> +    if ( xsm_ops_registered != XSM_OPS_UNREGISTERED )
>      {
> -        printk(XENLOG_ERR "Could not verify dummy_xsm_ops structure\n");
> +        printk(XENLOG_ERR
> +            "Could not init XSM, xsm_ops register already attempted\n");

Indentation.

>          return -EIO;
>      }
>  
> -    xsm_ops = &dummy_xsm_ops;
> +    /* install the dummy ops as default to ensure ops
> +     * are defined if requested policy fails init
> +     */
> +    xsm_fixup_ops(&xsm_ops);

/* Comment style. */

or

/*
 * Multi-
 * line comment style.
 */

>      switch ( xsm_bootparam )
>      {
>      case XSM_BOOTPARAM_DUMMY:
> +        xsm_ops_registered = XSM_OPS_REGISTERED;
>          break;
>  
>      case XSM_BOOTPARAM_FLASK:
> @@ -113,6 +117,9 @@ static int __init xsm_core_init(const void *policy_buffer, size_t policy_size)
>          break;
>      }
>  
> +    if ( xsm_ops_registered != XSM_OPS_REGISTERED )
> +        xsm_ops_registered = XSM_OPS_REG_FAILED;
> +
>      return 0;
>  }
>  
> @@ -197,16 +204,21 @@ bool __init has_xsm_magic(paddr_t start)
>  
>  int __init register_xsm(struct xsm_operations *ops)
>  {
> -    if ( verify(ops) )
> +    if ( xsm_ops_registered != XSM_OPS_UNREGISTERED )
> +        return -EAGAIN;

I know you moved this around the function, but it really isn't -EAGAIN
material any more.  It's "too late - nope".

-EEXIST is probably best for "I'm never going to tolerate another call".

> +
> +    if ( !ops )
>      {
> -        printk(XENLOG_ERR "Could not verify xsm_operations structure\n");
> +        xsm_ops_registered = XSM_OPS_REG_FAILED;
> +        printk(XENLOG_ERR "Invalid xsm_operations structure registered\n");
>          return -EINVAL;

Honestly, I'd be half tempted to declare register_xsm() with
__nonnull(0) and let the compiler reject any attempt to pass a NULL ops
pointer.

Both callers pass a pointer to a static singleton objects.

>      }
>  
> -    if ( xsm_ops != &dummy_xsm_ops )
> -        return -EAGAIN;
> +    /* use dummy ops for any empty ops */
> +    xsm_fixup_ops(ops);

Isn't this redundant with the call in xsm_core_init(), seeing as
register_xsm() must be nested within the switch statement?

> -    xsm_ops = ops;
> +    xsm_ops = *ops;
> +    xsm_ops_registered = XSM_OPS_REGISTERED;
>  
>      return 0;
>  }

Having got to the end, the xsm_core_init() vs register_xsm() dynamic is
quite weird.

I think it would result in clearer code to have init_{flask,silo}()
return pointers to their struct xsm_operations *, and let
xsm_core_init() do the copy in to xsm_ops.  This reduces the scope of
xsm_ops_state to this function only, and gets rid of at least one
runtime panic() call which is dead code.

If you were to go with this approach, you'd definitely want to split
into the 3-patch approach.

~Andrew



  reply	other threads:[~2021-06-18 11:35 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-17 23:39 [PATCH 0/6] xsm: refactoring xsm hooks Daniel P. Smith
2021-06-17 23:39 ` [PATCH 1/6] xsm: refactor xsm_ops handling Daniel P. Smith
2021-06-18 11:34   ` Andrew Cooper [this message]
2021-06-18 11:44     ` Jan Beulich
2021-06-18 11:45       ` Andrew Cooper
2021-06-18 16:26       ` Daniel P. Smith
2021-06-18 16:17     ` Daniel P. Smith
2021-07-12 12:36   ` [PATCH 0.5/6] xen: Implement xen/alternative-call.h for use in common code Andrew Cooper
2021-06-17 23:39 ` [PATCH 2/6] xsm: decouple xsm header inclusion selection Daniel P. Smith
2021-06-17 23:39 ` [PATCH 3/6] xsm: enabling xsm to always be included Daniel P. Smith
2021-06-18 11:53   ` Andrew Cooper
2021-06-18 16:35     ` Daniel P. Smith
2021-06-21  6:53       ` Jan Beulich
2021-06-24 17:18         ` Daniel P. Smith
2021-06-25  6:39           ` Jan Beulich
2021-06-18 12:26   ` Jan Beulich
2021-06-18 20:27     ` Daniel P. Smith
2021-06-21  6:58       ` Jan Beulich
2021-06-21 10:41         ` Andrew Cooper
2021-06-21 11:39           ` Jan Beulich
2021-06-18 21:20     ` Andrew Cooper
2021-06-21  7:03       ` Jan Beulich
2021-06-17 23:39 ` [PATCH 4/6] xsm: remove xen_defualt_t from hook definitions Daniel P. Smith
2021-06-18 11:56   ` Andrew Cooper
2021-06-18 16:35     ` Daniel P. Smith
2021-06-18 12:32   ` Jan Beulich
2021-06-17 23:39 ` [PATCH 5/6] xsm: expanding function related macros in dummy.h Daniel P. Smith
2021-06-18 12:03   ` Andrew Cooper
2021-06-18 12:40     ` Jan Beulich
2021-06-18 12:44       ` Jan Beulich
2021-06-18 16:38         ` Daniel P. Smith
2021-06-18 16:36     ` Daniel P. Smith
2021-06-17 23:39 ` [PATCH 6/6] xsm: removing the XSM_ASSERT_ACTION macro Daniel P. Smith
2021-06-18 10:14 ` [PATCH 0/6] xsm: refactoring xsm hooks Andrew Cooper
2021-06-18 11:48   ` Jan Beulich
2021-06-18 21:21     ` Andrew Cooper
2021-06-21  6:45       ` Jan Beulich
2021-06-18 15:53   ` Daniel P. Smith

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=07566583-d4bc-dfb8-eccd-d779783d959a@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=Volodymyr_Babchuk@epam.com \
    --cc=adam.schwalm@starlab.io \
    --cc=aisaila@bitdefender.com \
    --cc=christopher.w.clark@gmail.com \
    --cc=dfaggioli@suse.com \
    --cc=dgdegra@tycho.nsa.gov \
    --cc=dpsmith@apertussolutions.com \
    --cc=george.dunlap@citrix.com \
    --cc=iwj@xenproject.org \
    --cc=jbeulich@suse.com \
    --cc=jgross@suse.com \
    --cc=julien@xen.org \
    --cc=paul@xen.org \
    --cc=persaur@gmail.com \
    --cc=ppircalabu@bitdefender.com \
    --cc=roger.pau@citrix.com \
    --cc=scott.davis@starlab.io \
    --cc=sstabellini@kernel.org \
    --cc=tamas@tklengyel.com \
    --cc=tim@xen.org \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.