From: Doug Goldstein <firstname.lastname@example.org>
To: George Dunlap <George.Dunlap@citrix.com>
Cc: Sergey Dyasli <email@example.com>,
Stefano Stabellini <firstname.lastname@example.org>,
Julien Grall <email@example.com>, Wei Liu <firstname.lastname@example.org>,
Konrad Rzeszutek Wilk <email@example.com>,
Andrew Cooper <Andrew.Cooper3@citrix.com>,
Jan Beulich <firstname.lastname@example.org>,
Ian Jackson <Ian.Jackson@citrix.com>,
Daniel De Graaf <email@example.com>
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: <firstname.lastname@example.org> (raw)
On 1/11/20 3:02 AM, George Dunlap wrote:
>> On Jan 11, 2020, at 4:02 AM, Doug Goldstein <email@example.com> 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
>>> Signed-off-by: Sergey Dyasli <firstname.lastname@example.org>
>>> 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).
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
next prev parent 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
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.