Re: [Xen-devel] [PATCH v2] xsm: hide detailed Xen version from unprivileged guests

[Doug Goldstein <cardoe@xxxxxxxxxx>]

On 1/11/20 3:02 AM, George Dunlap wrote:
> > On Jan 11, 2020, at 4:02 AM, Doug Goldstein <cardoe@xxxxxxxxxx> 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 <sergey.dyasli@xxxxxxxxxx>
> > > ---
> > > 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
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel