All of
 help / color / mirror / Atom feed
From: Ian Jackson <>
To: Doug Goldstein <>
Cc: Sergey Dyasli <>,
	Stefano Stabellini <>,
	Julien Grall <>, Wei Liu <>,
	Konrad Rzeszutek Wilk <>,
	Andrew Cooper <>,
	George Dunlap <>,
	Xen-devel <>,
	Jan Beulich <>,
	Daniel De Graaf <>
Subject: Re: [Xen-devel] [PATCH v2] xsm: hide detailed Xen version from unprivileged guests
Date: Mon, 13 Jan 2020 14:01:23 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Doug Goldstein writes ("Re: [Xen-devel] [PATCH v2] xsm: hide detailed Xen version from unprivileged guests"):
> I'd be happy if we had a Kconfig option behind what the string is. Give 
> me a blank as an option but default it to whatever string like 
> "<hidden>" that you'd like. Every shipping Xen distro I've worked on has 
> had its own v1 variant of the patch and none of them authored by me.

Firstly: I generally agree with George's comments about not liking
silent failure, and I disagree with Andrew.  My inclination would be
to have this string be "<hidden>" (or similar) - and to not filter it
in the DMI tables, so it would be "<hidden>" everywhere.

Doug, I can't figure out from your messages whether that would meet
your needs ?  Is George right that the reason for filtering what used
to be "<denied>" is simply to reduce support burden due to the
negative connotations of "denied" ?  Would "hidden" fix that ?

If I am wrong, what is the reason for the filtering ?

If we have to have this string be configurable then so be it but I
would rather see if we can find one thing that meets downstreams'

FTR I agree with many of the points you make and I understand why you
think this is frustrating.  I hope we can clear this up.


Xen-devel mailing list

      parent reply	other threads:[~2020-01-13 14:01 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
2020-01-13 14:52         ` Julien Grall
2020-01-13 14:01       ` Ian Jackson [this message]

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:

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

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \

* 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.