[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v1] Add build-id to XENVER hypercall.
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@xxxxxxxxxx> 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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |