On 17/01/2023 4:21 pm, Jason Andryuk wrote: > 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
Thanks. > > 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? I noticed that during further testing. I made a modification to dummy in the same manner as flask. Given that it's the same piece of information (just with a less broken API), permission handling for the two ops should be the same. ~Andrew
