Re: [PATCH v3 2/3] xsm: consolidate loading the policy buffer

[Jan Beulich <jbeulich@xxxxxxxx>]

On 31.05.2022 17:08, Daniel P. Smith wrote:
> Previously, initializing the policy buffer was split between two functions,
> xsm_{multiboot,dt}_policy_init() and xsm_core_init(). The latter for loading
> the policy from boot modules and the former for falling back to built-in 
> policy.
> 
> This patch moves all policy buffer initialization logic under the
> xsm_{multiboot,dt}_policy_init() functions. It then ensures that an error
> message is printed for every error condition that may occur in the functions.
> With all policy buffer init contained and only called when the policy buffer
> must be populated, the respective xsm_{mb,dt}_init() functions will panic if 
> an
> error occurs attempting to populate the policy buffer.

"flask=late" is also a mode where, afaict, no policy is required. I can't,
however, see how you're taking care of that (but maybe I'm overlooking
something); inspecting flask_bootparam in generic XSM code would actually
be a layering violation.

> --- a/xen/include/xsm/xsm.h
> +++ b/xen/include/xsm/xsm.h
> @@ -775,7 +775,7 @@ int xsm_multiboot_init(
>      unsigned long *module_map, const multiboot_info_t *mbi);
>  int xsm_multiboot_policy_init(
>      unsigned long *module_map, const multiboot_info_t *mbi,
> -    void **policy_buffer, size_t *policy_size);
> +    const unsigned char *policy_buffer[], size_t *policy_size);

I don't think we're dealing with an array here, so const unsigned char **
would seem the more correct representation to me.

Also - what about the DT counterpart function?

Jan