[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 5/7] xsm: decouple xsm header inclusion selection


  • To: "Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 26 Aug 2021 10:13:05 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.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=fdcEZmaOcUppxVpKpDhiZgGDmoXT0mEZ+4TCEeTmcy0=; b=Uzj4TV8PRBDsNOCC5gXf7EKBlbAtYKgZWvJm7+/evYZFxGvzGPQGgY7Y9G4uBEFF4/mAuLjHJ9KG72RtFEwpjYOPVlrXasMpCpPiyTT1ddci5TNFiwcCHl86D5df8jxHDs5+mHKHxNfnfk/sxYXQfYvVSgBpXrS4MzPtYD8XUhUEiDMCF2xV8Y2evK04kBqFyKpxo9Uhc9CMRZQDtRLjCrSGEpOj+NrW0iwvHhiy7zp9OB+bcsXniS6NeQ1hMa/tG9lXlE/4blB1A02/XhUiD7Mo9Q0Kcknxe7F7LqRCxFKwXK3DuH+PHJg7RcOwSakjNyX01AVPnp6gyYrLAJqNrw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=R/qYbwJMoNgw9UYDSIW2a/l2Jm417L6WjPyongJIA3AKLcIHwcvszC5LwYcCUZWz0WiY49o9hrrBiSQT/A2fyg59ixIkQKqVR0cvbGNxii8XBh5TiqsThXA2PupPvolNlUhtwGO5bcq4GgRbchDZiBbkp5eG8ZUgu3Yh6ECrjnsWIwzzpqyf6mOb4G9IdnamK3OCM0JwjLe1iiv5DsvV5+/FBVeuQkXZgK2q2yaYQBuf1+MF1vvvLdZPU4xxpNuSVIl6+n8nH+jeBCGcIjTwpU0TLR/94BRWNZoFuLQXMLKSPi+y0nxfFqNYJTo9UXbm70Y3Zlp5guwxAJ57HOM0oA==
  • Authentication-results: lists.xenproject.org; dkim=none (message not signed) header.d=none;lists.xenproject.org; dmarc=none action=none header.from=suse.com;
  • Cc: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Thu, 26 Aug 2021 08:13:22 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 05.08.2021 16:06, Daniel P. Smith wrote:
> --- /dev/null
> +++ b/xen/include/xsm/xsm-core.h
> @@ -0,0 +1,273 @@
> +/*
> + *  This file contains the XSM hook definitions for Xen.
> + *
> + *  This work is based on the LSM implementation in Linux 2.6.13.4.
> + *
> + *  Author:  George Coker, <gscoker@xxxxxxxxxxxxxx>
> + *
> + *  Contributors: Michael LeMay, <mdlemay@xxxxxxxxxxxxxx>
> + *
> + *  This program is free software; you can redistribute it and/or modify
> + *  it under the terms of the GNU General Public License version 2,
> + *  as published by the Free Software Foundation.
> + */
> +
> +#ifndef __XSM_CORE_H__
> +#define __XSM_CORE_H__
> +
> +#include <xen/sched.h>
> +#include <xen/multiboot.h>

I was going to ask to invert the order (as we try to arrange #include-s
alphabetically), but it looks like multiboot.h isn't fit for this.

> +typedef void xsm_op_t;
> +DEFINE_XEN_GUEST_HANDLE(xsm_op_t);

Just FTR - I consider this dubious. If void is meant, I don't see why
a void handle can't be used.

> +/* policy magic number (defined by XSM_MAGIC) */
> +typedef uint32_t xsm_magic_t;
> +
> +#ifdef CONFIG_XSM_FLASK
> +#define XSM_MAGIC 0xf97cff8c
> +#else
> +#define XSM_MAGIC 0x0
> +#endif
> +
> +/* These annotations are used by callers and in dummy.h to document the
> + * default actions of XSM hooks. They should be compiled out otherwise.
> + */

I realize you only move code, but like e.g. the u32 -> uint32_t change
in context above I'd like to encourage you to also address other style
issues in the newly introduced file. Here I'm talking about comment
style, requiring /* to be on its own line.

> +enum xsm_default {
> +    XSM_HOOK,     /* Guests can normally access the hypercall */
> +    XSM_DM_PRIV,  /* Device model can perform on its target domain */
> +    XSM_TARGET,   /* Can perform on self or your target domain */
> +    XSM_PRIV,     /* Privileged - normally restricted to dom0 */
> +    XSM_XS_PRIV,  /* Xenstore domain - can do some privileged operations */
> +    XSM_OTHER     /* Something more complex */
> +};
> +typedef enum xsm_default xsm_default_t;
> +
> +struct xsm_ops {
> +    void (*security_domaininfo) (struct domain *d,

Similarly here (and below) - we don't normally put a blank between
the closing and opening parentheses in function pointer declarations.
The majority does so here, but ...

>[...]
> +    int (*page_offline)(uint32_t cmd);
> +    int (*hypfs_op)(void);

... there are exceptions.

>[...]
> +    int (*platform_op) (uint32_t cmd);
> +
> +#ifdef CONFIG_X86
> +    int (*do_mca) (void);
> +    int (*shadow_control) (struct domain *d, uint32_t op);
> +    int (*mem_sharing_op) (struct domain *d, struct domain *cd, int op);
> +    int (*apic) (struct domain *d, int cmd);
> +    int (*memtype) (uint32_t access);
> +    int (*machine_memory_map) (void);
> +    int (*domain_memory_map) (struct domain *d);
> +#define XSM_MMU_UPDATE_READ      1
> +#define XSM_MMU_UPDATE_WRITE     2
> +#define XSM_MMU_NORMAL_UPDATE    4
> +#define XSM_MMU_MACHPHYS_UPDATE  8
> +    int (*mmu_update) (struct domain *d, struct domain *t,
> +                       struct domain *f, uint32_t flags);
> +    int (*mmuext_op) (struct domain *d, struct domain *f);
> +    int (*update_va_mapping) (struct domain *d, struct domain *f,
> +                              l1_pgentry_t pte);
> +    int (*priv_mapping) (struct domain *d, struct domain *t);
> +    int (*ioport_permission) (struct domain *d, uint32_t s, uint32_t e,
> +                              uint8_t allow);
> +    int (*ioport_mapping) (struct domain *d, uint32_t s, uint32_t e,
> +                           uint8_t allow);
> +    int (*pmu_op) (struct domain *d, unsigned int op);
> +#endif
> +    int (*dm_op) (struct domain *d);

To match grouping elsewhere, a blank line above here, ...

> +    int (*xen_version) (uint32_t cmd);
> +    int (*domain_resource_map) (struct domain *d);
> +#ifdef CONFIG_ARGO

... and here would be nice.

> +    int (*argo_enable) (const struct domain *d);
> +    int (*argo_register_single_source) (const struct domain *d,
> +                                        const struct domain *t);
> +    int (*argo_register_any_source) (const struct domain *d);
> +    int (*argo_send) (const struct domain *d, const struct domain *t);
> +#endif
> +};
> +
> +extern void xsm_fixup_ops(struct xsm_ops *ops);
> +
> +#ifdef CONFIG_XSM
> +
> +#ifdef CONFIG_MULTIBOOT
> +extern int xsm_multiboot_init(unsigned long *module_map,
> +                              const multiboot_info_t *mbi);
> +extern int xsm_multiboot_policy_init(unsigned long *module_map,
> +                                     const multiboot_info_t *mbi,
> +                                     void **policy_buffer,
> +                                     size_t *policy_size);
> +#endif
> +
> +#ifdef CONFIG_HAS_DEVICE_TREE
> +/*
> + * Initialize XSM
> + *
> + * On success, return 1 if using SILO mode else 0.
> + */
> +extern int xsm_dt_init(void);
> +extern int xsm_dt_policy_init(void **policy_buffer, size_t *policy_size);
> +extern bool has_xsm_magic(paddr_t);
> +#endif
> +
> +#ifdef CONFIG_XSM_FLASK
> +extern const struct xsm_ops *flask_init(const void *policy_buffer,
> +                                        size_t policy_size);
> +#else
> +static inline const struct xsm_ops *flask_init(const void *policy_buffer,
> +                                               size_t policy_size)
> +{
> +    return NULL;
> +}
> +#endif
> +
> +#ifdef CONFIG_XSM_FLASK_POLICY
> +extern const unsigned char xsm_flask_init_policy[];
> +extern const unsigned int xsm_flask_init_policy_size;
> +#endif

To be honest, I don't think this belongs in any header. This interfaces
with a generated assembly file. In such a case I would always suggest
to limit visibility of the symbols as much as possible, i.e. put the
declarations in the sole file referencing them.

> +#ifdef CONFIG_XSM_SILO
> +extern const struct xsm_ops *silo_init(void);
> +#else
> +static const inline struct xsm_ops *silo_init(void)
> +{
> +    return NULL;
> +}
> +#endif
> +
> +#else /* CONFIG_XSM */
> +
> +#ifdef CONFIG_MULTIBOOT
> +static inline int xsm_multiboot_init (unsigned long *module_map,

Nit: Stray blank ahead of the opening parenthesis.

Looking back there's also the question of "extern" on function
declarations. In new code I don't think we put the redundant
storage class specifier there; they're only needed on data
declarations. I'm inclined to suggest to drop all of them while
moving the code.

Preferably with these adjustments
Acked-by: Jan Beulich <jbeulich@xxxxxxxx>

Jan




 


Rackspace

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