All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergey Dyasli <sergey.dyasli@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Doug Goldstein <cardoe@cardoe.com>
Cc: "sergey.dyasli@citrix.com >> Sergey Dyasli"
	<sergey.dyasli@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>, Wei Liu <wl@xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Xen-devel <xen-devel@lists.xen.org>,
	Jan Beulich <jbeulich@suse.com>,
	Ian Jackson <Ian.Jackson@citrix.com>,
	Daniel De Graaf <dgdegra@tycho.nsa.gov>
Subject: Re: [Xen-devel] [PATCH v2] xsm: hide detailed Xen version from unprivileged guests
Date: Tue, 14 Jan 2020 10:19:08 +0000	[thread overview]
Message-ID: <2f1e4eb2-1487-11ec-8a62-3c19372af4e5@citrix.com> (raw)
In-Reply-To: <52fcbff2-c175-745b-0c4a-d9ce6d4ae45e@citrix.com>

On 13/01/2020 14:40, Andrew Cooper wrote:
> On 13/01/2020 12:51, George Dunlap wrote:
>>   So Sergey's second patch:
>>  - Still denies XENVER_extraversion at the hypervisor level
>>  - Leaves the value returned by the hypervisor as "<denied>"
>>  - Filters the "<denied>" string at the hvmloader level, to prevent it
>> leaking into a GUI and scaring customers.
>
> The SMBios table isn't the only way XENVER_extraversion leaks up into
> the UI.
>
> XENVER_extraversion isn't the only source of redacted information
> leaking up into the UI.
>
> Linux for example exports it all via sysfs.  The windows drivers put
> XENVER_extraversion into several other logs.

I've found that /sys/hypervisor/version/extra returns "<denied>".
"<hidded>" would have looked better there.

>> Now we get to Andy's objection on the 10th:
>>
>> ---
>> 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.
>>
>> It is not appropriate for it to find its way into the guest in the first
>> place, and that includes turning up in `dmesg` and other logs, and
>> expecting guest runtime to filter for it is complete nonsense.
>> ---
>>
>> Basically, Andy says that *anywhere* it might show up is way too scary,
>> even a guest dmesg log.
>>
>> Well, I disagree; I look in "dmesg" and I see loads of "scary" things.
>
> Just because dmesg is not an example of a good UI, doesn't mean its ok
> for us to make:
>
> Xen version: 4.14<denied> (preserve-AD)

And the above is indeed found in dmesg of PV domains (they have no SMbios).
"<hidden>" is not appropriate here indeed. It should be either "" or
generic ".0" IMHO.

--
Thanks,
Sergey

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

  reply	other threads:[~2020-01-14 10:19 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ß
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 [this message]
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=2f1e4eb2-1487-11ec-8a62-3c19372af4e5@citrix.com \
    --to=sergey.dyasli@citrix.com \
    --cc=Ian.Jackson@citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=cardoe@cardoe.com \
    --cc=dgdegra@tycho.nsa.gov \
    --cc=george.dunlap@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=julien@xen.org \
    --cc=konrad.wilk@oracle.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.