From: Doug Goldstein <email@example.com> To: George Dunlap <George.Dunlap@citrix.com> Cc: Sergey Dyasli <firstname.lastname@example.org>, Stefano Stabellini <email@example.com>, Julien Grall <firstname.lastname@example.org>, Wei Liu <email@example.com>, Konrad Rzeszutek Wilk <firstname.lastname@example.org>, Andrew Cooper <Andrew.Cooper3@citrix.com>, Xen-devel <email@example.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) In-Reply-To: <865DBCFC-92C9-41D2-A502-914A5999979F@citrix.com> 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 >>> dmidecode. >>> 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). > > -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. -- Doug _______________________________________________ Xen-devel mailing list Xenemail@example.com https://lists.xenproject.org/mailman/listinfo/xen-devel
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 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: 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 \ --firstname.lastname@example.org \ --email@example.com \ --cc=Andrew.Cooper3@citrix.com \ --cc=George.Dunlap@citrix.com \ --cc=Ian.Jackson@citrix.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [Xen-devel] [PATCH v2] xsm: hide detailed Xen version from unprivileged guests' \ /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
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.