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

On 1/11/20 3:02 AM, George Dunlap wrote:
>> On Jan 11, 2020, at 4:02 AM, Doug Goldstein <> wrote:
>> On 1/10/20 4:37 AM, 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 <>
>>> ---
>>> v1 --> v2:
>>> - Added xsm_filter_denied() to hvmloader instead of modifying xen_deny()
>> So 100% this version of the patch won't fly with the various downstreams that run the v1 of this patch. Those various consumers will stick with v1.
>> If the goal of this is to reduce the burden of the downstreams and their customers to carry a patch against Xen then I wouldn't even bother with this version.
> If the goal is to come up with a solution that works for everyone, it would be helpful if you said *why* “various consumers” would find this patch unacceptable; and also what they might think about the alternate solutions proposed (and why).
>   -George

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.

Xen is a bit unique in the software world as most pieces of software 
aren't run in an "adversarial" environment. Look at any multi-tenant 
cloud provider. There's continually bad actors that are creating VMs and 
probing your system configurations and attempting to build a 
fingerprinting technique to identify exploitable systems vs not 
exploitable systems. Many security issues are dropped on providers 
without adequate time to patch all the systems prior to a disclosure. 
Look at systems like OpenXT, SecureView and Qubes where the users of 
these systems don't necessarily update to the latest fix immediately.

Now I know someone is going to read this and say "Look at Doug and him 
advocating for security through obscurity". But that's simply not the 
case. The point is anything that can be used to fingerprint a system 
easily and target an attack against that system is very different from 
saying my interfaces are secure because I don't publish the spec. When 
attackers are forced to probe a system it results in an opportunity to 
identity that behavior and take action.

I'll just end saying that stripping information in dom0 from the domU 
has not been considered acceptable in various circles because it changes 
the stance from "It is not possible to leak this data" to "This data 
cannot leak if action X happens correctly". Which then requires tests 
and documentation to show that it is not possible to leak.

Ultimately my point is if the goal of this patch is to upstream a patch 
that's carried by various downstreams, why not actually listen to what 
caused them to write the patch? In your other email you talk about 
developers being concerned about tracing the build of Xen or if they 
built it wrong. In the cases I'm talking about there's literally 0 
concern for that. The build of Xen is captured very well as an artifact 
of the deployment and certification of that build. The developers of 
that build of Xen know exactly the revision that the specific system is 
using and when they receive information they can go right to that revision.


Xen-devel mailing list

  reply	other threads:[~2020-01-12 18:27 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 [this message]
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:

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