On 17.12.2019 16:46, Sergey Dyasli wrote: > Hide the following information that can help identify the running Xen > binary version: > > XENVER_extraversion > XENVER_compile_info > XENVER_capabilities
What's wrong with exposing this one? > XENVER_changeset > XENVER_commandline > XENVER_build_id > > Return a more customer friendly empty string instead of "<denied>" > which would be shown in tools like dmidecode. I think "<denied>" is quite fine for many of the original purposes. Maybe it would be better to filter for this when populating guest DMI tables? > But allow guests to see this information in Debug builds of Xen. Behavior like this would imo better not differ between debug and release builds, or else guest software may behave entirely differently once you put it on a production build. > --- a/xen/include/xsm/dummy.h > +++ b/xen/include/xsm/dummy.h > @@ -750,16 +750,21 @@ static XSM_INLINE int xsm_xen_version (XSM_DEFAULT_ARG > uint32_t op) > case XENVER_get_features: > /* These sub-ops ignore the permission checks and return data. */ > return 0; > - case XENVER_extraversion: > - case XENVER_compile_info: > - case XENVER_capabilities: > - case XENVER_changeset: > case XENVER_pagesize: > case XENVER_guest_handle: > /* These MUST always be accessible to any guest by default. */ This comment, not the least because of its use of capitals, suggests to me that there's further justification needed for your change, including discussion of why there's no risk of breaking existing guests. > return xsm_default_action(XSM_HOOK, current->domain, NULL); > + > + case XENVER_extraversion: > + case XENVER_compile_info: > + case XENVER_capabilities: > + case XENVER_changeset: > + case XENVER_commandline: > + case XENVER_build_id: > default: There's no need to add all of these next to the default case. Note how commandline and build_id have been coming here already (and there would need to be further justification for exposing them on debug builds, should this questionable behavior - see above - be retained). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
