|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v3 5/7] xsm: decouple xsm header inclusion selection
On 8/26/21 4:13 AM, Jan Beulich wrote:
> 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.
So my understanding is to leave this as is.
>> +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.
Unless I am misunderstanding what you are calling for, I am afraid this
will trickle further that what intended to be addressed in this patch
set. If disagree and would like to provide me a suggest that stays
bounded, I would gladly incorporate.
>> +/* 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.
Ack.
>> +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 ...
Ack.
>> [...]
>> + 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, ...
Ack.
>> + int (*xen_version) (uint32_t cmd);
>> + int (*domain_resource_map) (struct domain *d);
>> +#ifdef CONFIG_ARGO
>
> ... and here would be nice.
Ack.
>> + 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.
Confirmed only used in xsm_core.c, so will move there.
>> +#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.
Ack.
> 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>
I believe I have pretty much incorporated all your adjustments. Will
include your Acked-by unless you feel I have not.
v/r,
dps
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |