Re: [PATCH v1] Add build-id to XENVER hypercall.

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Fri, Oct 09, 2015 at 01:15:42PM +0100, Andrew Cooper wrote:
> On 09/10/15 09:17, Jan Beulich wrote:
> >>>> On 09.10.15 at 04:56, <konrad.wilk@oracle.com> wrote:
> >> However they also change the behavior of the existing hypercall
> >> for XENVER_[compile_info|changeset|commandline] and make them
> >> dom0 accessible. This is if XSM is built in or not (though with
> >> XSM one can expose it to a guest if desired).
> > Wasn't the outcome of the previous discussion that we should not
> > alter default behavior for existing sub-ops?
> 
> I raised a worry that some guests might break if they suddenly have
> access to this information cut off.

Let me double-confirm that the guests are OK with this being
gone. I did ran tests to see if the worked, but hadn't actually tried
acessing (/sys/hypervisor/xen*) the values.

> 
> > And even if I'm
> > misremembering, I can see reasons for not exposing the command
> > line, but what value has not exposing compile info and changeset
> > again?
> 
> There is a fear that providing such information makes it easier for
> attackers who have an exploit for a specific binary.
> 
> > The more that the tool stack uses the two, and as we know
> > tool stacks or parts thereof can live in unprivileged domains.
> 
> I would argue than a fully unprivileged toolstack domain has no need for
> any information from this hypercall.  It it needs some privilege, then
> XSM is in use and it can be given access.

What he said :-)
> 
> > Plus
> > there is also a (hg-centric and hence generally broken) attempt to
> > store it in hvm_save().
> 
> I will be addressing this in due course with my further cpuid plans.
> 
> ~Andrew