All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Xin Li (Talons)" <xin.li@citrix.com>
To: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: XSM SILO boot time spew
Date: Thu, 1 Nov 2018 03:19:58 +0000	[thread overview]
Message-ID: <1541042398064.15504@citrix.com> (raw)
In-Reply-To: <8b666337-f1c9-8c1e-1a7d-f166a368a13f@citrix.com>

In patchset v4, we call register_xsm() to setup silo module.
This debug log is to check if some ops not overrided by the module.
I thought this is OK, since the log level is debug.

I think calling register_xsm() is good,
if we do want to suppress this debug log explicitly,
we can check if ops eqauls silo_xsm_ops in macro set_to_dummy_if_null().

The follow diff shows what I am suggesting, is it OK?

diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 3b192b5c31..b94fc43961 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -734,6 +734,7 @@ extern const unsigned int xsm_flask_init_policy_size;
 #endif
 
 #ifdef CONFIG_XSM_SILO
+extern struct xsm_operations silo_xsm_ops;
 extern void silo_init(void);
 #else
 static inline void silo_init(void) {}
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 06a674fad0..5af990514f 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -15,12 +15,20 @@
 
 struct xsm_operations dummy_xsm_ops;
 
+#ifdef CONFIG_XSM_SILO
+#define check_xsm_module(ops)                                          \
+    if (ops != &dummy_xsm_ops && ops != &silo_xsm_ops)
+#else
+#define check_xsm_module(ops)                                          \
+    if (ops != &dummy_xsm_ops)
+#endif
+
 #define set_to_dummy_if_null(ops, function)                            \
     do {                                                               \
         if ( !ops->function )                                          \
         {                                                              \
             ops->function = xsm_##function;                            \
-            if (ops != &dummy_xsm_ops)                                 \
+            check_xsm_module(ops)                                      \
                 dprintk(XENLOG_DEBUG, "Had to override the " #function \
                     " security operation with the dummy one.\n");      \
         }                                                              \
diff --git a/xen/xsm/silo.c b/xen/xsm/silo.c
index 4850756a3d..d2e6724e26 100644
--- a/xen/xsm/silo.c
+++ b/xen/xsm/silo.c
@@ -81,7 +81,7 @@ static int silo_grant_copy(struct domain *d1, struct domain *d2)
     return -EPERM;
 }
 
-static struct xsm_operations silo_xsm_ops = {
+struct xsm_operations silo_xsm_ops = {
     .evtchn_unbound = silo_evtchn_unbound,
     .evtchn_interdomain = silo_evtchn_interdomain,
     .grant_mapref = silo_grant_mapref,

________________________________________
From: Andrew Cooper
Sent: Wednesday, October 31, 2018 8:35 PM
To: Xen-devel List
Cc: Daniel De Graaf; Xin Li (Talons)
Subject: XSM SILO boot time spew

Hello,

I've noticed that the SILO code causes the following debug spew:

(XEN) XSM Framework v1.0.0 initialized
(XEN) Initialising XSM SILO mode
(XEN) dummy.c:31: Had to override the security_domaininfo security
operation with the dummy one.
(XEN) dummy.c:32: Had to override the domain_create security operation
with the dummy one.
...
(XEN) dummy.c:158: Had to override the xen_version security operation
with the dummy one.
(XEN) dummy.c:159: Had to override the domain_resource_map security
operation with the dummy one.
(XEN) microcode: CPU0 updated from revision 0x1a to 0x25, date = 2018-04-02
(XEN) xstate: size: 0x340 and states: 0x7

which is a side effect of silo_xsm_ops only implementing a few of the
hooks, falling back to dummy for the rest.

Presumably we don't want to special case SILO when overriding the
hooks.  Would having silo_init() explicitly copy from dummy be ok?

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2018-11-01  3:19 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-31 12:35 XSM SILO boot time spew Andrew Cooper
2018-11-01  3:19 ` Xin Li (Talons) [this message]
2018-11-07 17:52   ` Daniel De Graaf
2018-11-08  3:03     ` Xin Li (Talons)
2018-11-08 10:05     ` Jan Beulich
2018-11-08 10:13       ` Andrew Cooper

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=1541042398064.15504@citrix.com \
    --to=xin.li@citrix.com \
    --cc=Andrew.Cooper3@citrix.com \
    --cc=dgdegra@tycho.nsa.gov \
    --cc=xen-devel@lists.xen.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.