On Fri, Jan 13, 2023 at 6:08 PM Andrew Cooper <andrew.coop...@citrix.com> 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.coop...@citrix.com> > --- > CC: George Dunlap <george.dun...@eu.citrix.com> > CC: Jan Beulich <jbeul...@suse.com> > CC: Stefano Stabellini <sstabell...@kernel.org> > CC: Wei Liu <w...@xen.org> > CC: Julien Grall <jul...@xen.org> > CC: Daniel De Graaf <dgde...@tycho.nsa.gov> > CC: Daniel Smith <dpsm...@apertussolutions.com> > CC: Jason Andryuk <jandr...@gmail.com> > > 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 <jandr...@gmail.com> # 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
