All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jürgen Groß" <jgross@suse.com>
To: Jan Beulich <jbeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Sergey Dyasli <sergey.dyasli@citrix.com>,
	Lars Kurth <lars.kurth@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>, Wei Liu <wl@xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	George Dunlap <george.dunlap@citrix.com>,
	xen-devel@lists.xen.org, Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH v2] xsm: hide detailed Xen version from unprivileged guests
Date: Fri, 10 Jan 2020 17:45:32 +0100	[thread overview]
Message-ID: <e57a35f1-1c81-8393-0efd-c3592aa69dd2@suse.com> (raw)
In-Reply-To: <01239ba8-9084-faff-c9f7-f59970aefd82@suse.com>

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.dyasli@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.cooper3@citrix.com>
>>>> CC: George Dunlap <George.Dunlap@eu.citrix.com>
>>>> CC: Ian Jackson <ian.jackson@eu.citrix.com>
>>>> CC: Jan Beulich <jbeulich@suse.com>
>>>> CC: Julien Grall <julien@xen.org>
>>>> CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>>> CC: Stefano Stabellini <sstabellini@kernel.org>
>>>> CC: Wei Liu <wl@xen.org>
>>>> CC: Daniel De Graaf <dgdegra@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. :-)


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2020-01-10 16:45 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-10 10:37 [Xen-devel] [PATCH v2] xsm: hide detailed Xen version from unprivileged guests Sergey Dyasli
2020-01-10 11:02 ` Andrew Cooper
2020-01-10 15:28   ` George Dunlap
2020-01-10 15:56     ` Jan Beulich
2020-01-10 16:45       ` Jürgen Groß [this message]
2020-01-10 17:00         ` George Dunlap
2020-01-11  3:55     ` Doug Goldstein
2020-01-11  9:35       ` George Dunlap
2020-01-13 11:01   ` Sergey Dyasli
2020-01-10 11:09 ` Jan Beulich
2020-01-11  4:02 ` Doug Goldstein
2020-01-11  9:02   ` George Dunlap
2020-01-12 18:26     ` Doug Goldstein
2020-01-13 12:51       ` George Dunlap
2020-01-13 13:39         ` Julien Grall
2020-01-13 14:01           ` Andrew Cooper
2020-01-13 14:07             ` George Dunlap
2020-01-13 14:28               ` Julien Grall
2020-01-13 14:40         ` Andrew Cooper
2020-01-14 10:19           ` Sergey Dyasli
2020-01-13 14:52         ` Julien Grall
2020-01-13 14:01       ` Ian Jackson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e57a35f1-1c81-8393-0efd-c3592aa69dd2@suse.com \
    --to=jgross@suse.com \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=dgdegra@tycho.nsa.gov \
    --cc=george.dunlap@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=jbeulich@suse.com \
    --cc=julien@xen.org \
    --cc=konrad.wilk@oracle.com \
    --cc=lars.kurth@citrix.com \
    --cc=sergey.dyasli@citrix.com \
    --cc=sstabellini@kernel.org \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.