Re: [Xen-devel] [PATCH v3 1/3] xen/flask: Drop the gen-policy.py script

[Daniel De Graaf]

On 12/7/19 4:16 PM, Andrew Cooper wrote:

The script is Python 2 specific, and fails with string/binary issues with
Python 3:

   Traceback (most recent call last):
 File "gen-policy.py", line 14, in 
   for char in sys.stdin.read():
 File "/usr/lib/python3.5/codecs.py", line 321, in decode
   (result, consumed) = self._buffer_decode(data, self.errors, final)
   UnicodeDecodeError: 'utf-8' codec can't decode byte 0x8c in position 0: 
invalid start byte

Fixing the script to be compatible isn't hard, but using python here is
wasteful.  Drop the script entirely, and write a short flask-policy.S instead.

Signed-off-by: Andrew Cooper 


Acked-by: Daniel De Graaf 

With either .align or .p2align as appropriate for more assemblers.

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

Re: [Xen-devel] [PATCH for-4.13] xen/xsm: flask: Prevent NULL deference in flask_assign_{, dt}device()

[Daniel De Graaf]

On 10/4/19 12:42 PM, Julien Grall wrote:

flask_assign_{, dt}device() may be used to check whether you can test if
a device is assigned. In this case, the domain will be NULL.

However, flask_iommu_resource_use_perm() will be called and may end up
to deference a NULL pointer. This can be prevented by moving the call
after we check the validity for the domain pointer.

Coverity-ID: 1486741
Fixes: 71e617a6b8 ('use is_iommu_enabled() where appropriate...')
Signed-off-by: Julien Grall 


Acked-by: Daniel De Graaf 

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

Re: [Xen-devel] [PATCH for-4.13] xen/xsm: flask: Check xmalloc_array() return in security_sid_to_context()

[Daniel De Graaf]

On 10/4/19 12:56 PM, Julien Grall wrote:

xmalloc_array() may return NULL if there are memory. Rather than trying
to deference it directly, we should check the return value first.

Coverity-ID: 1381852
Signed-off-by: Julien Grall 

Acked-by: Daniel De Graaf 

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

Re: [Xen-devel] [PATCH RESEND v1 1/8] stubdom/vtpm: include stdio.h for declaration of printf

[Daniel De Graaf]

On 9/24/19 10:03 AM, Olaf Hering wrote:

The function read_vtpmblk uses printf(3), but stdio.h is not included
in this file. This results in a warning from gcc-7:

vtpmblk.c: In function 'read_vtpmblk':
vtpmblk.c:322:7: warning: implicit declaration of function 'printf' 
[-Wimplicit-function-declaration]
printf("Expected: ");
vtpmblk.c:322:7: warning: incompatible implicit declaration of built-in 
function 'printf'
vtpmblk.c:322:7: note: include '' or provide a declaration of 'printf'

Signed-off-by: Olaf Hering 

Acked-by: Daniel De Graaf 

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

Re: [Xen-devel] [PATCH v6 07/10] use is_iommu_enabled() where appropriate...

[Daniel De Graaf]

On 8/16/19 1:19 PM, Paul Durrant wrote:

...rather than testing the global iommu_enabled flag and ops pointer.

Now that there is a per-domain flag indicating whether the domain is
permitted to use the IOMMU (which determines whether the ops pointer will
be set), many tests of the global iommu_enabled flag and ops pointer can
be translated into tests of the per-domain flag. Some of the other tests of
purely the global iommu_enabled flag can also be translated into tests of
the per-domain flag.

NOTE: The comment in iommu_share_p2m_table() is also fixed; need_iommu()
   disappeared some time ago. Also, whilst the style of the 'if' in
   flask_iommu_resource_use_perm() is fixed, I have not translated any
   instances of u32 into uint32_t to keep consistency. IMO such a
   translation would be better done globally for the source module in
   a separate patch.
   The change in the initialization of the 'hd' variable in iommu_map()
   and iommu_unmap() is done to keep the PV shim build happy. Without
   this change it will fail to compile with errors of the form:

iommu.c:361:32: error: unused variable ‘hd’ [-Werror=unused-variable]
  const struct domain_iommu *hd = dom_iommu(d);
  ^~

Signed-off-by: Paul Durrant 


Acked-by: Daniel De Graaf 


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

Re: [Xen-devel] [PATCH v6 04/10] domain: remove the 'is_xenstore' flag

[Daniel De Graaf]

On 8/16/19 1:19 PM, Paul Durrant wrote:

This patch introduces a convenience macro, is_xenstore_domain(), which
tests the domain 'options' directly and then uses that in place of
the 'is_xenstore' flag.

Signed-off-by: Paul Durrant 
Reviewed-by: "Roger Pau Monné" 
Acked-by: George Dunlap 


Acked-by: Daniel De Graaf 

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

Re: [Xen-devel] [PATCH 4/4] drop __get_cpu_var() and __get_cpu_ptr()

[Daniel De Graaf]

On 6/14/19 11:38 AM, Jan Beulich wrote:

this_cpu{,_ptr}() are shorter, and have previously been marked as
preferred in Xen anyway.

Signed-off-by: Jan Beulich 


Acked-by: Daniel De Graaf 

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

Re: [Xen-devel] [PATCH v1] stubdom/vtpm: include stdio.h for declaration of printf

[Daniel De Graaf]

On 5/29/18 8:06 AM, Olaf Hering wrote:

The function read_vtpmblk uses printf(3), but stdio.h is not included
in this file. This results in a warning from gcc-7:

vtpmblk.c: In function 'read_vtpmblk':
vtpmblk.c:322:7: warning: implicit declaration of function 'printf' 
[-Wimplicit-function-declaration]
printf("Expected: ");
vtpmblk.c:322:7: warning: incompatible implicit declaration of built-in 
function 'printf'
vtpmblk.c:322:7: note: include '' or provide a declaration of 'printf'

Signed-off-by: Olaf Hering 


Acked-by: Daniel De Graaf 

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

Re: [Xen-devel] [PATCH v5 4/4] x86/mem_sharing: compile mem_sharing subsystem only when kconfig is enabled

[Daniel De Graaf]

On 6/3/19 4:26 AM, Jan Beulich wrote:

On 16.05.19 at 23:37,  wrote:

Disable it by default as it is only an experimental subsystem.

Signed-off-by: Tamas K Lengyel 


Daniel, it looks like you weren't Cc-ed here, but your ack is needed.

Jan


Acked-by: Daniel De Graaf 

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

Re: [Xen-devel] [PATCH v2 1/2] xen: add interface for obtaining .config from hypervisor

[Daniel De Graaf]

On 3/14/19 7:59 AM, Juergen Gross wrote:

Add a sysctl interface for obtaining the .config file used to build
the hypervisor. The mechanism is inspired by the Linux kernel's one.

Signed-off-by: Juergen Gross 
Reviewed-by: Jan Beulich  (apart from XSM changes)


Acked-by: Daniel De Graaf 



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

Re: [Xen-devel] [PATCH for-4.12 RFC] xen/console: Handle NUL character in buffer sent via CONSOLEIO_write

[Daniel De Graaf]

On 2/27/19 1:45 PM, Julien Grall wrote:

Hi Wei,

On 2/27/19 12:55 PM, Wei Liu wrote:

On Tue, Feb 26, 2019 at 11:03:51PM +, Julien Grall wrote:

After upgrading Debian to Buster, I started noticing console mangling
when using zsh. This is happenning because output sent by zsh to the
console may contain NUL character in the middle of the buffer.

Linux is sending the buffer as it is to Xen console via CONSOLEIO_write.
However, the implementation in Xen considers NUL character is used to
terminate the buffer and therefore will ignore anything after it.

The actual documentation of CONSOLEIO_write is pretty limited. From the
declaration, the hypercall takes a buffer and size. So this could lead
to think the NUL character is allowed in the middle of the buffer.

This patch updates the console API to pass the size along the buffer
down so we can remove the reliance on buffer terminating by a NUL
character.

Signed-off-by: Julien Grall 

---


[...]

@@ -527,7 +527,7 @@ static inline void xen_console_write_debug_port(const char 
*buf, size_t len)
  static long guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer, int 
count)
  {
  char kbuf[128];
-    int kcount = 0;
+    unsigned int kcount = 0;
  struct domain *cd = current->domain;
  while ( count > 0 )
@@ -547,8 +547,8 @@ static long 
guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer, int count)
  /* Use direct console output as it could be interactive */
  spin_lock_irq(_lock);
-    sercon_puts(kbuf);
-    video_puts(kbuf);
+    sercon_puts(kbuf, kcount);
+    video_puts(kbuf, kcount);


I think you missed the non-hwdom branch in the same function. It still
strips non-printable characters.


Good point. The non-printable characters was added by Daniel in commit 48d50de8e0 " 
console: buffer and show origin of guest PV writes" without much explanation.


Yes, I added stripping of non-printable characters because escape sequences 
printed out by some guests (in particular, clear screen sequences printed out 
by some distro's early boot scripts) interfered with the output of other 
guests.  It also prevents guests from pretending to be one another or the 
hypervisor, if the console is being used for some kind of auditing or logging.

One thing I didn't consider that I probably should have is that isprint() in 
the hypervisor is not a UTF-8 aware check, so it will end up corrupting 
characters if your guests treat the console as having that encoding.


The only reason I can see is, as we buffer the guest writes, the console would be screwed 
if we split an escape sequence. Furthermore, for guest output, we will always append 
"(dX)" to the output. So I am not entirely sure what to do in the non-hwdom 
case.

Any opinions?


This really depends on the purpose of the console in the system.  Since there's 
usually possible hypervisor messages in the output, it makes sense to me to 
treat it as a line-based log containing readable text.  However, the ability 
for the hardware domain to use it interactively is also important for 
debugging, and limiting or buffering that domain's output would interfere with 
that.  The current handling of the output is a compromise between these two 
uses.

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

Re: [Xen-devel] [PATCH v3 5/6] xen/x86: add PHYSDEVOP_msi_msix_set_enable

[Daniel De Graaf]

On 1/30/19 8:51 AM, Roger Pau Monné wrote:

On Sat, Jan 26, 2019 at 03:31:16AM +0100, Marek Marczykowski-Górecki wrote:

Allow device model running in stubdomain to enable/disable MSI(-X),
bypassing pciback. While pciback is still used to access config space
from within stubdomain, it refuse to write to
PCI_MSI_FLAGS_ENABLE/PCI_MSIX_FLAGS_ENABLE in non-permissive mode. Which
is the right thing to do for PV domain (the main use case for pciback),
as PV domain should use XEN_PCI_OP_* commands for that. Unfortunately
those commands are not good for stubdomain use, as they configure MSI in
dom0's kernel too, which should not happen for HVM domain.

This new physdevop is allowed only for stubdomain controlling the domain
which own the device.

Signed-off-by: Marek Marczykowski-Górecki 


Thanks!


---
Changes in v3:
  - new patch

This is rather RFC. Any suggestions for shorter name? Also, I'm not sure
if physdev_msi_msix_set_enable.flag is the best name/idea.


I've made some comments below.


Should it be plugged into XSM? Any suggestions how exactly? New
function with XSM_DM_PRIV default action? Should it get target domain
only, or also machine_bdf?


You should Cc the XSM maintainer I think, which I've done now.


Yes, I think you need to pass both the domain and machine_bdf; the hook
sounds like it should be similar to the existing map_domain_irq or
assign_device hooks: check that the device model has rights to do this
operation on the device, and also check that the device model has rights
to modify devices assigned to the device's owner (this check is why the
domain is needed).

Alternatively, you can hard-code the requirement to be the target domain,
but I think this prevents using the same hooks from a dom0 device model.
If that's already the case, this is less of an issue.

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

Re: [Xen-devel] [PATCH v9 1/7] xen: xsm: flask: introduce XENMAPSPACE_gmfn_share for memory sharing

[Daniel De Graaf]

On 12/5/18 5:15 PM, Stefano Stabellini wrote:

From: Zhongze Liu 

The existing XENMAPSPACE_gmfn_foreign subop of XENMEM_add_to_physmap forbids
a Dom0 to map memory pages from one DomU to another, which restricts some useful
yet not dangerous use cases -- such as sharing pages among DomU's so that they
can do shm-based communication.

This patch introduces XENMAPSPACE_gmfn_share to address this inconvenience,
which is mostly the same as XENMAPSPACE_gmfn_foreign but has its own xsm check.

Specifically, the patch:

* Introduces a new av permission MMU__SHARE_MEM to denote if two domains can
   share memory by using the new subop;
* Introduces xsm_map_gmfn_share() to check if (current) has proper permission
   over (t) AND MMU__SHARE_MEM is allowed between (d) and (t);
* Modify the default xen.te to allow MMU__SHARE_MEM for normal domains that
   allow grant mapping/event channels.

The new subop is marked unsupported for x86 because calling p2m_add_foregin
on two DomU's is currently not supported on x86.

This is for the proposal "Allow setting up shared memory areas between VMs
from xl config file" (see [1]).

[1] https://lists.xen.org/archives/html/xen-devel/2017-08/msg03242.html

Signed-off-by: Zhongze Liu 
Signed-off-by: Stefano Stabellini [...]
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index b0ac1f6..9d109b0 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -535,6 +535,20 @@ static XSM_INLINE int xsm_map_gmfn_foreign(XSM_DEFAULT_ARG 
struct domain *d, str
 return xsm_default_action(action, d, t);
 }
 
+/*

+ * Be aware that this is not an exact default equivalence of its flask
+ * variant which also checks if @d and @t "are allowed to share memory
+ * pages", for now, we don't have a proper default equivalence of such a
+ * check.
+ */
+static XSM_INLINE int xsm_map_gmfn_share(XSM_DEFAULT_ARG struct domain *d,
+ struct domain *t)
+{
+XSM_ASSERT_ACTION(XSM_TARGET);
+return xsm_default_action(action, current->domain, d) ?:
+   xsm_default_action(action, current->domain, t);
+}


In all of the callers that I checked, we've already made a call to the
xsm_add_to_physmap hook checking that (current) can modify (d), so the
check here is redundant.  If it's useful to keep the redundant check in
case another caller is added later (or if there's one I missed), it would
also be useful to re-verify the MMU__PHYSMAP permission in the flask code
so that the checks remain equivalent.

If you want the comment on the (d,t) check documented in code, the XSM_HOOK
action is a useful no-op.

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

Re: [Xen-devel] [PATCH v2 3/3] docs: remove tmem related text

[Daniel De Graaf]

On 11/28/18 8:58 AM, Wei Liu wrote:

Signed-off-by: Wei Liu 


Acked-by: Daniel De Graaf 

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

Re: [Xen-devel] [PATCH v2 2/3] xen: remove tmem from hypervisor

[Daniel De Graaf]

On 11/28/18 8:58 AM, Wei Liu wrote:

This patch removes all tmem related code and CONFIG_TMEM from the
hypervisor. Also remove tmem hypercalls from the default XSM policy.

It is written as if tmem is disabled and tmem freeable pages is 0.

We will need to keep public/tmem.h around forever to avoid breaking
guests.  Remove the hypervisor only part and put guest visible part
under a xen version check. Take the chance to remove trailing
whitespaces.

Signed-off-by: Wei Liu 


Acked-by: Daniel De Graaf 

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

Re: [Xen-devel] XSM SILO boot time spew

[Daniel De Graaf]

On 10/31/2018 11:19 PM, Xin Li (Talons) wrote:

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?


If SILO is a good example of what a potential third XSM module would look
like, it's probably better to just remove the printing and allow the
dummy module's hooks to fill in any null values in the xsm_operations
structure.  The printing part was written with FLASK and ACM in mind,
which both intended to hook everything and might add new hooks without
changing the other.

Another possible solution would be to add a bool parameter to register_xsm
that disables the warnings instead of checking the pointer value, but that
feels like overkill to me; we still only have two XSM modules.

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

[Xen-devel] [PATCH] flask/policy: allow dom0 to use PHYSDEVOP_pci_mmcfg_reserved

[Daniel De Graaf]

Reported-by: Andrew Cooper 
Signed-off-by: Daniel De Graaf 
---
 tools/flask/policy/modules/dom0.te | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/flask/policy/modules/dom0.te 
b/tools/flask/policy/modules/dom0.te
index dfdcdcd128..a0566671d6 100644
--- a/tools/flask/policy/modules/dom0.te
+++ b/tools/flask/policy/modules/dom0.te
@@ -66,6 +66,9 @@ allow dom0_t security_t:security { load_policy setenforce 
setbool };
 # Audit policy change events even when they are allowed
 auditallow dom0_t security_t:security { load_policy setenforce setbool };
 
+# Allow dom0 to report platform configuration changes back to the hypervisor
+allow dom0_t xen_t:resource setup;
+
 admin_device(dom0_t, device_t)
 admin_device(dom0_t, irq_t)
 admin_device(dom0_t, ioport_t)
-- 
2.14.5


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

Re: [Xen-devel] [PATCH v5 1/3] xen/xsm: remove unnecessary #define

[Daniel De Graaf]

On 10/09/2018 05:33 AM, Xin Li wrote:

this #define is unnecessary since XSM_INLINE is redefined in
xsm/dummy.h, it's a risk of build breakage, so remove it.

Signed-off-by: Xin Li 
Reviewed-by: Jan Beulich 


Acked-by: Daniel De Graaf 

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

[Xen-devel] [PATCH v2] flask: sort io{port,mem}con entries

[Daniel De Graaf]

These entries are not always sorted by checkpolicy, so sort them during
policy load (as is already done for later ocontext additions).

Reported-by: Nicolas Poirot 
Signed-off-by: Daniel De Graaf 
---
 xen/xsm/flask/ss/policydb.c | 35 +--
 1 file changed, 29 insertions(+), 6 deletions(-)

diff --git a/xen/xsm/flask/ss/policydb.c b/xen/xsm/flask/ss/policydb.c
index 3a12d96ef9..9426164353 100644
--- a/xen/xsm/flask/ss/policydb.c
+++ b/xen/xsm/flask/ss/policydb.c
@@ -1737,7 +1737,7 @@ int policydb_read(struct policydb *p, void *fp)
 {
 struct role_allow *ra, *lra;
 struct role_trans *tr, *ltr;
-struct ocontext *l, *c /*, *newc*/;
+struct ocontext *l, *c, **pn;
 int i, j, rc;
 __le32 buf[8];
 u32 len, /*len2,*/ config, nprim, nel /*, nel2*/;
@@ -1994,6 +1994,7 @@ int policydb_read(struct policydb *p, void *fp)
 if ( rc < 0 )
 goto bad;
 nel = le32_to_cpu(buf[0]);
+pn = >ocontexts[i];
 l = NULL;
 for ( j = 0; j < nel; j++ )
 {
@@ -2003,11 +2004,6 @@ int policydb_read(struct policydb *p, void *fp)
 rc = -ENOMEM;
 goto bad;
 }
-if ( l )
-l->next = c;
-else
-p->ocontexts[i] = c;
-l = c;
 rc = -EINVAL;
 switch ( i )
 {
@@ -2050,6 +2046,18 @@ int policydb_read(struct policydb *p, void *fp)
 rc = context_read_and_validate(>context, p, fp);
 if ( rc )
 goto bad;
+
+if ( *pn || ( l && l->u.ioport.high_ioport >= 
c->u.ioport.low_ioport ) )
+{
+pn = >ocontexts[i];
+l = *pn;
+while ( l && l->u.ioport.high_ioport < 
c->u.ioport.low_ioport ) {
+pn = >next;
+l = *pn;
+}
+c->next = l;
+}
+l = c;
 break;
 case OCON_IOMEM:
 if ( p->target_type != TARGET_XEN )
@@ -2078,6 +2086,18 @@ int policydb_read(struct policydb *p, void *fp)
 rc = context_read_and_validate(>context, p, fp);
 if ( rc )
 goto bad;
+
+if ( *pn || ( l && l->u.iomem.high_iomem >= 
c->u.iomem.low_iomem ) )
+{
+pn = >ocontexts[i];
+l = *pn;
+while ( l && l->u.iomem.high_iomem < c->u.iomem.low_iomem 
) {
+pn = >next;
+l = *pn;
+}
+c->next = l;
+}
+l = c;
 break;
 case OCON_DEVICE:
 if ( p->target_type != TARGET_XEN )
@@ -2123,6 +2143,9 @@ int policydb_read(struct policydb *p, void *fp)
 rc = -EINVAL;
 goto bad;
 }
+
+*pn = c;
+pn = >next;
 }
 }
 
-- 
2.14.4


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

[Xen-devel] [PATCH] flask: Add check for io{port,mem}con sorting

[Daniel De Graaf]

These entries are not always sorted by checkpolicy.  Enforce the sorting
(which can be done manually if using an unpatched checkpolicy) when
loading the policy so that later uses by the security server do not
incorrectly use the initial sid.

Reported-by: Nicolas Poirot 
Signed-off-by: Daniel De Graaf 
---
 xen/xsm/flask/ss/policydb.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/xen/xsm/flask/ss/policydb.c b/xen/xsm/flask/ss/policydb.c
index 3a12d96ef9..fcf63693b9 100644
--- a/xen/xsm/flask/ss/policydb.c
+++ b/xen/xsm/flask/ss/policydb.c
@@ -2007,7 +2007,6 @@ int policydb_read(struct policydb *p, void *fp)
 l->next = c;
 else
 p->ocontexts[i] = c;
-l = c;
 rc = -EINVAL;
 switch ( i )
 {
@@ -2050,6 +2049,12 @@ int policydb_read(struct policydb *p, void *fp)
 rc = context_read_and_validate(>context, p, fp);
 if ( rc )
 goto bad;
+if ( l && l->u.ioport.high_ioport > c->u.ioport.low_ioport )
+{
+printk(KERN_ERR
+"Flask: Invalid policy, ioportcon not sorted\n");
+goto bad;
+}
 break;
 case OCON_IOMEM:
 if ( p->target_type != TARGET_XEN )
@@ -2078,6 +2083,12 @@ int policydb_read(struct policydb *p, void *fp)
 rc = context_read_and_validate(>context, p, fp);
 if ( rc )
 goto bad;
+if ( l && l->u.iomem.high_iomem > c->u.iomem.low_iomem )
+{
+printk(KERN_ERR
+"Flask: Invalid policy, iomemcon not sorted\n");
+goto bad;
+}
 break;
 case OCON_DEVICE:
 if ( p->target_type != TARGET_XEN )
@@ -2123,6 +2134,7 @@ int policydb_read(struct policydb *p, void *fp)
 rc = -EINVAL;
 goto bad;
 }
+l = c;
 }
 }
 
-- 
2.14.4


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

Re: [Xen-devel] [Xen-users] XSM/Flask iomem

[Daniel De Graaf]

This is apparently a mismatch between what the checkpolicy compilation does
and what it is expected to do.  While some parts of checkpolicy do this
sorting, the main compilation flow does not, and the policy compilation
process does not ensure inputs are sorted.  In the future, newer versions
of checkpolicy should fix this bug.  Newer versions of Xen may also start
checking this ordering on policy load (I'll submit a patch to do this).

This bug also applies to I/O ports, but not the other types of policy
items (IRQs, PCI devices, or devicetree).  It will cause non-sorted entries
to be skipped in most cases, instead querying the default sid, but larger
iomem/ioport ranges might also query the skipped entry (always in addition
to the default).

Until the fixed version of checkpoicy is released and adopted, policy
writers can manually sort their iomem/ioport ranges as a workaround.

On 09/27/2018 06:18 AM, George Dunlap wrote:

[Moving to xen-devel]

Daniel,

Any comments on this one?

  -George
On Wed, Sep 26, 2018 at 12:41 PM  wrote:


Hi,

I just noticed from a bad behaviour of my installation and the 
security_iterate_iomem_sids
function that the iomem ranges have to be sorted in the device_contexts file.
The flask load policy takes iomem ranges declaration as it comes but the sid 
attribution
and check function expects the list of iomem ocontexts to be sorted.
My file didn't comply with this statement which ended to use the default iomem 
sid instead
of computing one before checking the permission.

This doesn't seem to be documented anywhere in the xen release 4.11.0.

Thanks.

Nicolas
1


___
Xen-users mailing list
xen-us...@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-users



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

Re: [Xen-devel] [PATCH 2/2] xen/xsm: Add new SILO mode for XSM

[Daniel De Graaf]

On 09/28/2018 04:18 AM, Xin Li wrote:

When SILO is enabled, there would be no page-sharing or event notifications
between unprivileged VMs (no grant tables or event channels).

Signed-off-by: Xin Li 

v3: make copies of dummy functions to avoid indirect call.


This still makes indirect calls.  You will need to #include xsm/dummy.h,
and a third case in line 44's #ifdef CONFIG_XSM / #else may be required
to adjust XSM_INLINE to avoid compiler warnings.

The function xsm_fixup_ops() will already set the unused parts of your
xsm_operations struct to the dummy functions; you don't need to do that
in silo_init by copying dummy_xsm_ops.  You should use register_xsm to
assign to xsm_ops instead of doing it yourself.

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

Re: [Xen-devel] [PATCH 1/2] xen/xsm: Introduce new boot parameter xsm

[Daniel De Graaf]

On 09/28/2018 04:18 AM, Xin Li wrote:

Introduce new boot parameter xsm to choose which xsm module is enabled,
and set default to dummy.

Signed-off-by: Xin Li 


This changes the default behavior of a hypervisor compiled with XSM+FLASK when
booted with no command line arguments from enabling FLASK to enabling the dummy
module.  I think the default value of the "xsm=" parameter should be settable
in Kconfig to allow existing systems to continue working after an upgrade.

If not, this new command line argument needs to be mentioned in more locations
in the documentation; at least docs/misc/xsm-flask "Setting up FLASK" will need
to mention it.  I think a mention in the release notes for the next version is
also a good idea (in addition to or as part of the note on the new SILO 
feature),
but that's not a part of the patch.

Untested Kconfig snippet:

choice
prompt "Default XSM implementation"
default XSM_FLASK_DEFAULT if XSM_FLASK
default XSM_SILO_DEFAULT if XSM_SILO
default XSM_DUMMY_DEFAULT
config XSM_DUMMY_DEFAULT
bool "Match non-XSM behavior"
config XSM_FLASK_DEFAULT
bool "FLux Advanced Security Kernel" if XSM_FLASK
config XSM_SILO_DEFAULT
bool "SILO" if XSM_SILO
endchoice

The multiple "default" statements are intended to cause the default to be the
chosen enabled system, or dummy if there are no existing Kconfig settings.

I also think the question for XSM_FLASK should be removed from EXPERT now that
there is a reason to enable XSM without FLASK.

The name "default" might end up being misleading in this case; "none", "off",
or "dummy" might be better.


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

Re: [Xen-devel] [PATCH 05/12] xen: add hypercall interfaces for domain and cpupool parameter setting

[Daniel De Graaf]

On 09/18/2018 02:03 AM, Juergen Gross wrote:

Add a new domctl for setting domain specific parameters similar to
XEN_SYSCTL_set_parameter for global hypervisor parameters.

Enhance XEN_SYSCTL_set_parameter to be usable for setting cpupool
specific parameters, too. For now do only extended parameter checking.
The cpupool parameter setting will be added later.

Signed-off-by: Juergen Gross 


You also need to add the permission to the create_domain_common macro
in xen.if (currently you only let dom0 modify its own settings).  If
you intend this interface to be used to modify running domains, adding
it to the manage_domain macro would also be useful, but that's not as
critical.

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

Re: [Xen-devel] [PATCH v1 6/6] xsm: add tee access policy support

[Daniel De Graaf]

On 08/23/2018 09:32 AM, Volodymyr Babchuk wrote:

Hello Daniel,

On 23.08.18 01:44, DeGraaf, Daniel G wrote:

From: Volodymyr Babchuk 
Sent: Wednesday, August 22, 2018 10:12 AM

As we don't want any guest to access limited resources of TEE, we need a way to 
control who can work with it.

Thus, new access vector class "tee" is added with only ony operation "call" so 
far. tee framework uses this to check if guest has a right
to work with TEE.

Also, example security context domU_with_tee_t was added.

Are you planning to add more access vectors to this class in the future? 
Otherwise, it probably doesn't need its own class - since you use xen_t as the 
target, placing it in class xen/xen2 is preferred (like tmem and others are 
now).



At the moment I can't imagine any other vectors. Reason I created a new class 
is that it seemed wrong to me to use generic xen/xen2 class, because, strictly 
speaking, this vector have nothing to do with xen core.

But, if you think that it is appropriate to have vector "tee_call" in xen2 
class, then I can move it there.


Actually, upon further thought it may better fit in the resource class:
there are already "resource use" and "resource setup" permissions there
that deal with some platform-wide objects.  If there will only ever be
one TEE device, a tee_call permission with target xen_t will cover it,
but this allows for a more natural extension to multiple TEEs (or a TEE
with some hypervisor-inspected function-level access control) that are
themselves labeled like we do for PCI devices.  That's probably not
relevant to this design until someone makes such an interface, however,
so I'd continue using xen_t until then.

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

Re: [Xen-devel] [PATCH v2 13/13] x86/domctl: Implement XEN_DOMCTL_get_cpu_policy

[Daniel De Graaf]

On 07/13/2018 04:03 PM, Andrew Cooper wrote:

From: Sergey Dyasli 

This finally (after literally years of work!) marks the point where the
toolstack can ask the hypervisor for the current CPUID configuration of a
specific domain.

Also extend xen-cpuid's --policy mode to be able to take a domid and dump a
specific domains CPUID and MSR policy.

Signed-off-by: Andrew Cooper 
Signed-off-by: Sergey Dyasli 


Since this is a read operation, it should have a new access vector (probably
get_cpuid) instead of sitting under set_cpuid so that it is possible to allow
viewing the policy without allowing it to be changed (useful for migration out,
introspection, or duplicating the settings on a now-protected domain).

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

Re: [Xen-devel] [PATCH v5 06/15] public / x86: introduce __HYPERCALL_iommu_op

[Daniel De Graaf]

On 08/03/2018 01:22 PM, Paul Durrant wrote:

This patch introduces the boilerplate for a new hypercall to allow a
domain to control IOMMU mappings for its own pages.
Whilst there is duplication of code between the native and compat entry
points which appears ripe for some form of combination, I think it is
better to maintain the separation as-is because the compat entry point
will necessarily gain complexity in subsequent patches.

NOTE: This hypercall is only implemented for x86 and is currently
   restricted by XSM to dom0. Its scope can be expanded in future
   if need be.

Signed-off-by: Paul Durrant 


Acked-by: Daniel De Graaf 

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

Re: [Xen-devel] [PATCH v2 03/21] xen: allow console_io hypercalls from certain DomUs

[Daniel De Graaf]

On 07/19/2018 05:19 AM, Julien Grall wrote:

Hi Stefano,

On 18/07/18 18:10, Stefano Stabellini wrote:

On Tue, 17 Jul 2018, Julien Grall wrote:

Hi Stefano,

On 17/07/2018 21:05, Stefano Stabellini wrote:

On Mon, 9 Jul 2018, Julien Grall wrote:

Hi,

On 07/07/18 00:11, Stefano Stabellini wrote:

Introduce an is_console option to allow certain classes of domUs to use
the Xen console. Specifically, it will be used to give console access to
all domUs started from Xen from information on device tree.

Signed-off-by: Stefano Stabellini 
CC: andrew.coop...@citrix.com
CC: george.dun...@eu.citrix.com
CC: ian.jack...@eu.citrix.com
CC: jbeul...@suse.com
CC: konrad.w...@oracle.com
CC: t...@xen.org
CC: wei.l...@citrix.com
CC: dgde...@tycho.nsa.gov
---
Changes in v2:
- introduce is_console
- remove #ifdefs
---
    xen/include/xen/sched.h | 2 ++
    xen/include/xsm/dummy.h | 2 ++
    xen/xsm/flask/hooks.c   | 5 -
    3 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 99d2af2..d66cec0 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -379,6 +379,8 @@ struct domain
    bool auto_node_affinity;
    /* Is this guest fully privileged (aka dom0)? */
    bool is_privileged;
+    /* Can this guest access the Xen console? */
+    bool is_console;
    /* Is this a xenstore domain (not dom0)? */
    bool is_xenstore;
    /* Domain's VCPUs are pinned 1:1 to physical CPUs? */
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index ff6b2db..317 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -230,6 +230,8 @@ static XSM_INLINE int
xsm_memory_stat_reservation(XSM_DEFAULT_ARG struct domain
    static XSM_INLINE int xsm_console_io(XSM_DEFAULT_ARG struct domain
*d, int
cmd)
    {
    XSM_ASSERT_ACTION(XSM_OTHER);
+    if ( d->is_console )
+    return xsm_default_action(XSM_HOOK, d, NULL);


I will let Daniel commenting on this change. However ...


    #ifdef CONFIG_VERBOSE_DEBUG
    if ( cmd == CONSOLEIO_write )
    return xsm_default_action(XSM_HOOK, d, NULL);
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 78bc326..2551e4e 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -443,7 +443,10 @@ static int flask_console_io(struct domain *d, int
cmd)
    return avc_unknown_permission("console_io", cmd);
    }
    -    return domain_has_xen(d, perm);
+    if ( !d->is_console )
+    return domain_has_xen(d, perm);
+    else
+    return 0;


... I don't think this change is correct. When a policy is used, the user
is
free to define what is the behavior. With your solution, you impose the
console access even if the user didn't to not give the permission.


I was hoping Daniel would advise on the best way to do things here.

I thought that the idea was that granting a domain "is_console" is
equivalent to granting a domain XEN__READCONSOLE and XEN__WRITECONSOLE
permissions.  Thus, if is_console is set, we return 0 from
flask_console_io because the permissions check succeeds.


Well, yes and no. That's equivalent when you use the dummy policy. When you
have a flask policy you want to give the control to the user.

If you look at the code there are no such as d->is_privilege in that function.
This means that the user define the policy for the hardware domain. Why would
be d->is_console different here?


You are saying that in hooks.c the check should remain exactly as is:

   return domain_has_xen(d, perm);

and d->is_console should not be tested?


Yes.


In that case, do you know if I
need to do anything special with XEN__READCONSOLE and XEN__WRITECONSOLE
permissions for the initial boot domains (such as adding those
permissions as the same time d->is_console is set)?


The main purpose of XSM is to provide a fine grain permission for the user to 
configure. For instance, a user may not console access for initial domain for 
security purpose. So you don't have anything to in the code.

However, when you have XSM enabled, you will have to write down in the policy 
that initial domains will have console access. Although, I am not sure how to 
write that in the policy.


In a security policy that wishes to make this distinction, the initial domains 
will
have distinct security labels from domains created later.  Then, those types are
allowed console_write access (along with any other special rights they may 
need).

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

Re: [Xen-devel] [PATCH v3 01/25] xen: allow console_io hypercalls from certain DomUs

[Daniel De Graaf]

On 07/31/2018 07:27 PM, Stefano Stabellini wrote:

Introduce an is_console option to allow certain classes of domUs to use
the Xen console. Specifically, it will be used to give console access to
all domUs started from Xen from information on device tree.

Signed-off-by: Stefano Stabellini 


Acked-by: Daniel De Graaf 

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

Re: [Xen-devel] [PATCH 2/2] xen/xsm: Add new SILO mode for XSM

[Daniel De Graaf]

On 07/24/2018 04:18 AM, Xin Li (Talons) wrote:

  Hi Daniel,

  I think the main questions here are:
  1. Do we need a separated KConfig option for SILO


Yes; I made comments on your patch doing so


  2. Can we use indirect call like "dummy_xsm_ops.grant_copy"
  Any suggestion?


It would be nice to avoid it.  Making a global dummy_xsm_grant_copy()
function would be better, though the best location of the prototype and
code isn't obvious.

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

Re: [Xen-devel] [PATCH 1/2] xen/xsm: Introduce new boot parameter xsm

[Daniel De Graaf]

On 07/02/2018 09:26 PM, Xin Li wrote:

Introduce new boot parameter xsm to choose which xsm module is enabled,
and set default to dummy.

Signed-off-by: Xin Li 


This is a change in defaults for the command line: previously, if you
compiled Xen with FLASK support, Xen defaulted to using it unless you
specified "flask=disabled" on the command line.  If we want to model the
interface after Linux, there would be a KConfig choice of the default
which can be overridden by the command line, so distributions can keep
current behavior (including making the default dummy while enabling the
other XSM modules).

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

Re: [Xen-devel] [PATCH 2/2] xen/xsm: Rename CONIFIG_XSM_POLICY to CONFIG_XSM_FLASK_POLICY

[Daniel De Graaf]

On 06/26/2018 07:09 AM, Andrew Cooper wrote:

The embedded policy is specific flask, so update the infrastructure to reflect
this.

Signed-off-by: Andrew Cooper 


This one actually has a history of being shared between FLASK and ACM (the
now-removed alternative to FLASK in earlier versions of Xen).  However, the
current policy generation is very specific to FLASK, and it would be useful
to allow multiple security modules to each have their own default policy.

Overall, I think it's a useful change.  Is there a reason you chose the
prefix "xsm_init_flask" over "xsm_flask_init"?  The latter may be more
amenable to grepping.

Either way,

Acked-by: Daniel De Graaf 

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

Re: [Xen-devel] [PATCH 1/2] xen/xsm: Rename CONFIG_FLASK_* to CONFIG_XSM_FLASK_*

[Daniel De Graaf]

On 06/26/2018 07:09 AM, Andrew Cooper wrote:

Flask is one single XSM module, and another is about to be introduced.
Properly namespace the symbols for clarity.

No functional change.

Signed-off-by: Andrew Cooper 


Acked-by: Daniel De Graaf 


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

Re: [Xen-devel] [PATCH 10/20] xen/domctl: Merge set_max_evtchn into createdomain

[Daniel De Graaf]

On 03/19/2018 03:13 PM, Andrew Cooper wrote:

set_max_evtchn is somewhat weird.  It was introduced with the event_fifo work,
but has never been used.  Still, it is a bounding on resources consumed by the
event channel infrastructure, and should be part of createdomain, rather than
editable after the fact.

Drop XEN_DOMCTL_set_max_evtchn completely (including XSM hooks and libxc
wrappers), and retain the functionality in XEN_DOMCTL_createdomain.

Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com>


Acked-by: Daniel De Graaf <dgde...@tycho.nsa.gov>

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

Re: [Xen-devel] [PATCH 12/20] xen/domctl: Merge max_vcpus into createdomain

[Daniel De Graaf]

On 03/19/2018 03:13 PM, Andrew Cooper wrote:

XEN_DOMCTL_max_vcpus is a mandatory hypercall, but nothing actually prevents a
toolstack from unpausing a domain with no vcpus.

Originally, d->vcpus[] was an embedded array in struct domain, but c/s
fb442e217 "x86_64: allow more vCPU-s per guest" in Xen 4.0 altered it to being
dynamically allocated.  A side effect of this is that d->vcpu[] is NULL until
XEN_DOMCTL_max_vcpus has completed, but a lot of hypercalls blindly
dereference it.

Even today, the behaviour of XEN_DOMCTL_max_vcpus is a mandatory singleton
call which can't change the number of vcpus once a value has been chosen.
Therefore, delete XEN_DOMCTL_max_vcpus (including XSM hooks and toolstack
wrappers) and retain the functionality in XEN_DOMCTL_createdomain.

This will allow future cleanup to ensure that d->vcpus[] is always valid for a
locatable domain, and allow simplification of some creation logic which needs
to size domain-wide objects based on max_cpus, which currently have to be
deferred until vcpu construction.

For the python stubs, extend the domain_create keyword list to take a
max_vcpus parameter, in lieu of deleting the pyxc_domain_max_vcpus function.

Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com>


Acked-by: Daniel De Graaf <dgde...@tycho.nsa.gov>

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

Re: [Xen-devel] [PATCH] xsm:schedop: introduce vcpuinfo permissions verification

[Daniel De Graaf]

On 02/15/2018 05:51 AM, Andrii Anisov wrote:

From: Andrii Anisov <andrii_ani...@epam.com>

Introduce per-vcpu scheduler operations permission verification.
As long as Xvcpuinfo are in fact scheduler configuration manipulations
there is no need to introduce specific access vectors.

Signed-off-by: Andrii Anisov <andrii_ani...@epam.com>


Acked-by: Daniel De Graaf <dge...@tycho.nsa.gov>

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

Re: [Xen-devel] [PATCH v4] new config option vtsc_tolerance_khz to avoid TSC emulation

[Daniel De Graaf]

On 03/09/2018 09:10 AM, Olaf Hering wrote:

Add an option to control when vTSC emulation will be activated for a
domU with tsc_mode=default. Without such option each TSC access from
domU will be emulated, which causes a significant perfomance drop for
workloads that make use of rdtsc.

Add a new domctl XEN_DOMCTL_set_vtsc_tolerance_khz to adjust the
tolerance value of a running domU that is supposed to be migrated.

One option to avoid the TSC option is to run domUs with tsc_mode=native.
This has the drawback that migrating a domU from a "2.3GHz" class host
to a "2.4GHz" class host may change the rate at wich the TSC counter
increases, the domU may not be prepared for that.

With this option the host admin can decide how a domU should behave when
it is migrated across systems of the same class. Since there is always
some jitter when Xen calibrates the cpu_khz value, all hosts of the same
class will most likely have slightly different values. As a result vTSC
emulation is unavoidable. Data collected during the incident which
triggered this change showed a jitter of up to 200 KHz across systems of
the same class.

A new utility is added which allows to adjust the vtsc_tolerance_khz
value for running domUs. This is useful to avoid emulation for domUs
that are already running and which can not be restarted.

The ordering of records sent during migration is important. The value of
vtsc_tolerance_khz must be known by the receiving host before
configuring TSC, because this is the place where the decision of vTSC
emulation is made. Therefore the existing write_tsc_info function is
modified to enforce that ordering.

v4:
  - add missing copyback in XEN_DOMCTL_set_vtsc_tolerance_khz
v3:
  - rename vtsc_khz_tolerance to vtsc_tolerance_khz
  - separate domctls to adjust values
  - more docs
  - update libxl.h
  - update python tests
  - flask check bound to tsc permissions
  - not runtime tested due to dlsym() build errors in staging

Signed-off-by: Olaf Hering <o...@aepfle.de>


Acked-by: Daniel De Graaf <dgde...@tycho.nsa.gov>

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

Re: [Xen-devel] [PATCH] xen: Fix XSM build after dropping XEN_DOMCTL_getmemlist

[Daniel De Graaf]

On 01/26/2018 02:34 PM, Andrew Cooper wrote:

c/s 94450e36bfbb removed XEN_DOMCTL_getmemlist entirely, but missed adjusting
the XSM side of things.  As far as I can tell, 'pagelist' wasn't even offered
to dom0 in default policy.

Also, drop the stale struct xen_domctl_getmemlist which was missed from the
same changeset.

Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com>


Acked-by: Daniel De Graaf <dgde...@tycho.nsa.gov>

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

Re: [Xen-devel] [PATCH v3 6/7] xsm: add bodge when compiling with llvm coverage support

[Daniel De Graaf]

On 01/24/2018 05:01 AM, Roger Pau Monne wrote:

llvm coverage support seems to disable some of the optimizations
needed in order to compile xsm, and the end result is that references
to __xsm_action_mismatch_detected are left in the object files.

Since coverage support cannot be used in production, introduce
__xsm_action_mismatch_detected for llvm coverage builds.

Signed-off-by: Roger Pau Monné <roger@citrix.com>


Acked-by: Daniel De Graaf <dgde...@tycho.nsa.gov>

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

Re: [Xen-devel] [RFC PATCH 1/8] x86/domctl: introduce a pair of hypercall to set and get cpu topology

[Daniel De Graaf]

On 01/09/2018 04:06 AM, Chao Gao wrote:

On Mon, Jan 08, 2018 at 01:14:44PM -0500, Daniel De Graaf wrote:

On 01/07/2018 11:01 PM, Chao Gao wrote:

Define interface, structures and hypercalls for toolstack to build
cpu topology and for guest that will retrieve it [1].
Two subop hypercalls introduced by this patch:
XEN_DOMCTL_set_cpu_topology to define cpu topology information per domain
and XENMEM_get_cpu_topology to retrieve cpu topology information.

[1]: during guest creation, those information helps hvmloader to build ACPI.

Signed-off-by: Chao Gao <chao@intel.com>


When adding new XSM controls for use by device models, you also
need to add the permissions to the device_model macro defined in
tools/flask/policy/modules/xen.if.  If domains need to call this
function on themselves (is this only true for get?), you will also
need to add it to declare_domain_common.



Hi, Daniel.

Yes. XENMEM_get_cpu_topology will be called by the domain itself.
And Both get and set will be called by dom0 when creating one domain.
So I need:
1. add *set* and *get* to create_domain_common.
2. add *set* to declare_domain_common.

Is it right?

Thanks
Chao


It sounds like you need to add get to declare_domain_common (not set)
because the domain only needs to invoke this on itself.  If the device
model doesn't need to use these hypercalls (would guest cpu hotplug or
similar things need them?), then that's all you need to add.

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

Re: [Xen-devel] [RFC PATCH 1/8] x86/domctl: introduce a pair of hypercall to set and get cpu topology

[Daniel De Graaf]

On 01/07/2018 11:01 PM, Chao Gao wrote:

Define interface, structures and hypercalls for toolstack to build
cpu topology and for guest that will retrieve it [1].
Two subop hypercalls introduced by this patch:
XEN_DOMCTL_set_cpu_topology to define cpu topology information per domain
and XENMEM_get_cpu_topology to retrieve cpu topology information.

[1]: during guest creation, those information helps hvmloader to build ACPI.

Signed-off-by: Chao Gao 


When adding new XSM controls for use by device models, you also
need to add the permissions to the device_model macro defined in
tools/flask/policy/modules/xen.if.  If domains need to call this
function on themselves (is this only true for get?), you will also
need to add it to declare_domain_common.


---
  xen/arch/x86/domctl.c   | 27 ++
  xen/arch/x86/hvm/hvm.c  |  7 ++
  xen/arch/x86/mm.c   | 45 +
  xen/include/asm-x86/hvm/domain.h| 15 +
  xen/include/public/domctl.h | 22 ++
  xen/include/public/memory.h | 27 +-
  xen/include/xsm/dummy.h |  6 +
  xen/xsm/dummy.c |  1 +
  xen/xsm/flask/hooks.c   | 10 +
  xen/xsm/flask/policy/access_vectors |  4 
  10 files changed, 163 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 36ab235..4e1bbd5 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -347,6 +347,29 @@ void arch_get_domain_info(const struct domain *d,
  info->flags |= XEN_DOMINF_hap;
  }
  
+static int arch_set_cpu_topology(struct domain *d,

+ struct xen_domctl_cpu_topology *topology)
+{
+if ( !is_hvm_domain(d) ||
+ !topology->size || topology->size > HVM_MAX_VCPUS )
+return -EINVAL;
+
+if ( !d->arch.hvm_domain.apic_id )
+d->arch.hvm_domain.apic_id = xmalloc_array(uint32_t, topology->size);
+
+if ( !d->arch.hvm_domain.apic_id )
+return -ENOMEM;
+
+if ( copy_from_guest(d->arch.hvm_domain.apic_id, topology->tid,
+ topology->size) )
+return -EFAULT;
+
+d->arch.hvm_domain.apic_id_size = topology->size;
+d->arch.hvm_domain.core_per_socket = topology->core_per_socket;
+d->arch.hvm_domain.thread_per_core = topology->thread_per_core;
+return 0;
+}
+
  #define MAX_IOPORTS 0x1
  
  long arch_do_domctl(

@@ -1555,6 +1578,10 @@ long arch_do_domctl(
  recalculate_cpuid_policy(d);
  break;
  
+case XEN_DOMCTL_set_cpu_topology:

+ret = arch_set_cpu_topology(d, >u.cpu_topology);
+break;
+
  default:
  ret = iommu_do_domctl(domctl, d, u_domctl);
  break;
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 71fddfd..b3b3224 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1509,6 +1509,13 @@ int hvm_vcpu_initialise(struct vcpu *v)
  int rc;
  struct domain *d = v->domain;
  
+if ( v->vcpu_id > d->arch.hvm_domain.apic_id_size )

+{
+printk(XENLOG_ERR "d%dv%d's apic id isn't set.\n",
+   d->domain_id, v->vcpu_id);
+return -ENOENT;
+}
+
  hvm_asid_flush_vcpu(v);
  
  spin_lock_init(>arch.hvm_vcpu.tm_lock);

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index a56f875..b90e663 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4413,6 +4413,51 @@ long arch_memory_op(unsigned long cmd, 
XEN_GUEST_HANDLE_PARAM(void) arg)
  return rc;
  }
  
+case XENMEM_get_cpu_topology:

+{
+struct domain *d;
+struct xen_cpu_topology_info topology;
+
+if ( copy_from_guest(, arg, 1) )
+return -EFAULT;
+
+if ( topology.pad || topology.pad2 )
+return -EINVAL;
+
+if ( (d = rcu_lock_domain_by_any_id(topology.domid)) == NULL )
+return -ESRCH;
+
+rc = xsm_get_cpu_topology(XSM_TARGET, d);
+if ( rc )
+goto get_cpu_topology_failed;
+
+rc = -EOPNOTSUPP;
+if ( !is_hvm_domain(d) || !d->arch.hvm_domain.apic_id )
+goto get_cpu_topology_failed;
+
+/* allow the size to be zero for users who don't care apic_id */
+if ( topology.size )
+{
+rc = -E2BIG;
+if ( topology.size != d->arch.hvm_domain.apic_id_size )
+goto get_cpu_topology_failed;
+
+rc = -EFAULT;
+if ( copy_to_guest(topology.tid.h, d->arch.hvm_domain.apic_id,
+   topology.size) )
+goto get_cpu_topology_failed;
+}
+
+topology.core_per_socket = d->arch.hvm_domain.core_per_socket;
+topology.thread_per_core = d->arch.hvm_domain.thread_per_core;
+
+rc = __copy_to_guest(arg, , 1) ? -EFAULT : 0;
+
+ get_cpu_topology_failed:
+rcu_unlock_domain(d);
+   

Re: [Xen-devel] [PATCH 2/3] x86/xsm: Use the exported bootstrap_map() function

[Daniel De Graaf]

On 01/08/2018 06:56 AM, Andrew Cooper wrote:

... rather than obtaining it via function pointer.

Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com>


Acked-by: Daniel De Graaf <dgde...@tycho.nsa.gov>

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

Re: [Xen-devel] [PATCH 3/3] XSM/flask: constification of IRQ mapping interfaces

[Daniel De Graaf]

On 12/04/2017 05:34 AM, Jan Beulich wrote:

This clarifies that the involved structures are read-only.

Signed-off-by: Jan Beulich <jbeul...@suse.com>


Acked-by: Daniel De Graaf <dgde...@tycho.nsa.gov>

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

Re: [Xen-devel] [PATCH] XSM: add Kconfig option to override bootloader provided policy

[Daniel De Graaf]

On 11/28/2017 01:06 PM, Tamas K Lengyel wrote:

From: Tamas K Lengyel <lengy...@ainfosec.com>

Currently the built-in XSM policy only gets used if there is no other policy
specified during boot. In this patch we add a Kconfig option to specify to only
use built-in policy during boot. This is particularly important when booting
Xen through the shim to ensure the XSM policy gets measured and that it can't
be replaced by another unmeasured policy by the bootloader. Note that the XSM
policy can still be updated after boot (from dom0 for example) if the built-in
policy allows it.

Signed-off-by: Tamas K Lengyel <lengy...@ainfosec.com>


Acked-by: Daniel De Graaf <dgde...@tycho.nsa.gov>

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