On 1/10/20 4:45 PM, Jürgen Groß wrote: > On 10.01.20 16:56, Jan Beulich wrote: >> On 10.01.2020 16:28, George Dunlap wrote: >>> On 1/10/20 11:02 AM, Andrew Cooper wrote: >>>> On 10/01/2020 10:37, Sergey Dyasli wrote: >>>>> Hide the following information that can help identify the running Xen >>>>> binary version: XENVER_extraversion, XENVER_compile_info, >>>>> XENVER_changeset. >>>>> Add explicit cases for XENVER_commandline and XENVER_build_id as well. >>>>> >>>>> Introduce xsm_filter_denied() to hvmloader to remove "<denied>" string >>>>> from guest's DMI tables that otherwise would be shown in tools like >>>>> dmidecode. >>>>> >>>>> Signed-off-by: Sergey Dyasli <sergey.dya...@citrix.com> >>>>> --- >>>>> v1 --> v2: >>>>> - Added xsm_filter_denied() to hvmloader instead of modifying >>>>> xen_deny() >>>>> - Made behaviour the same for both Release and Debug builds >>>>> - XENVER_capabilities is no longer hided >>>>> >>>>> CC: Andrew Cooper <andrew.coop...@citrix.com> >>>>> CC: George Dunlap <george.dun...@eu.citrix.com> >>>>> CC: Ian Jackson <ian.jack...@eu.citrix.com> >>>>> CC: Jan Beulich <jbeul...@suse.com> >>>>> CC: Julien Grall <jul...@xen.org> >>>>> CC: Konrad Rzeszutek Wilk <konrad.w...@oracle.com> >>>>> CC: Stefano Stabellini <sstabell...@kernel.org> >>>>> CC: Wei Liu <w...@xen.org> >>>>> CC: Daniel De Graaf <dgde...@tycho.nsa.gov> >>>> >>>> I realise there are arguments over how to fix this, but we (the Xen >>>> community) have already f*cked up once here, and this is doing so a >>>> second time. >>>> >>>> Nack. >>>> >>>> Fixing it anywhere other than Xen is simply not appropriate. >> >> (replying here, because the original mail doesn't seem to have >> made it into my inbox) >> >> I've said so to Sergey already on v1: The "fix" you want needs to >> be at or closer to the presentation layer. From Xen's perspective >> the request for information was _indeed_ denied. >> >>>> The reason for this (which ought to be obvious, but I guess only to >>>> those who actually do customer support) is basic human physiology. >>>> "denied" means something has gone wrong. It scares people, and causes >>>> them to seek help to change fix whatever is broken. >>> >>> This seems like a reasonable argument that "<denied>" causes issues. >>> But that doesn't change the fact that "" also causes issues. >>> >>> What about changing the string to "<build-id hidden>" or something like >>> that? That makes it more clear what would have been in that place, and >>> "hidden" is a lot less scary than "denied". >> >> I could live with this. But (judging from the picture that was >> provided earlier on) it would still require filtering at or close >> to the presentation layer, and by changing the prior <denied> to >> different and varying strings may make that job harder (albeit >> perhaps they could look for any <...>). > > I'd go with "<hidden>" or "<NIL>". "<build-id hidden>" as value for the > build-id is similar to "LCD-display". And it will certainly not be the > correct value for other hidden items. :-)
The idea is that in a log, if you see a buildid in context, you can usually figure out what it is just by looking at it; i.e..: Xen 4.13.1 8a2a24f4e1 So which is better? 1. Xen 4.13.1 2. Xen 4.13.1 <hidden> 3 Xen 4.13.1 <buildid hidden> 4 Xen 4.13.1 <NIL> I don't like 1 or 4. I could live with 2 I guess. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
