Re: [PATCH v2 3/5] xen/version: Introduce non-truncating XENVER_* subops

[Jason Andryuk <jandryuk@xxxxxxxxx>]

On Fri, Jan 13, 2023 at 6:08 PM Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
>
> Recently in XenServer, we have encountered problems caused by both
> XENVER_extraversion and XENVER_commandline having fixed bounds.
>
> More than just the invariant size, the APIs/ABIs also broken by typedef-ing an
> array, and using an unqualified 'char' which has implementation-specific
> signed-ness
>
> Provide brand new ops, which are capable of expressing variable length
> strings, and mark the older ops as broken.
>
> This fixes all issues around XENVER_extraversion being longer than 15 chars.
> More work is required to remove other assumptions about XENVER_commandline
> being 1023 chars long.
>
> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> ---
> CC: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
> CC: Jan Beulich <JBeulich@xxxxxxxx>
> CC: Stefano Stabellini <sstabellini@xxxxxxxxxx>
> CC: Wei Liu <wl@xxxxxxx>
> CC: Julien Grall <julien@xxxxxxx>
> CC: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>
> CC: Daniel Smith <dpsmith@xxxxxxxxxxxxxxxxxxxx>
> CC: Jason Andryuk <jandryuk@xxxxxxxxx>
>
> v2:
>  * Remove xen_capabilities_info_t from the stack now that arch_get_xen_caps()
>    has gone.
>  * Use an arbitrary limit check much lower than INT_MAX.
>  * Use "buf" rather than "string" terminology.
>  * Expand the API comment.
>
> Tested by forcing XENVER_extraversion to be 20 chars long, and confirming that
> an untruncated version can be obtained.
> ---
>  xen/common/kernel.c          | 62 +++++++++++++++++++++++++++++++++++++++++++
>  xen/include/public/version.h | 63 
> ++++++++++++++++++++++++++++++++++++++++++--
>  xen/include/xlat.lst         |  1 +
>  xen/xsm/flask/hooks.c        |  4 +++

The Flask change looks good, so that part is:
Reviewed-by: Jason Andryuk <jandryuk@xxxxxxxxx> # Flask

Looking at include/xsm/dummy.h, these new subops would fall under the
default case and require XSM_PRIV.  Is that the desired permission,
and guests would just have to handle EPERM?

Regards,
Jason