xen-devel.lists.xenproject.org archive mirror
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).