[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v12 1/9] x86: add generic resource (e.g. MSR) access hypercall
On 08/07/14 08:06, Xu, Dongxiao wrote: >> -----Original Message----- >> From: Andrew Cooper [mailto:andrew.cooper3@xxxxxxxxxx] >> Sent: Friday, July 04, 2014 6:53 PM >> To: Jan Beulich; Xu, Dongxiao; xen-devel@xxxxxxxxxxxxx >> Cc: Ian.Campbell@xxxxxxxxxx; George.Dunlap@xxxxxxxxxxxxx; >> Ian.Jackson@xxxxxxxxxxxxx; stefano.stabellini@xxxxxxxxxxxxx; >> konrad.wilk@xxxxxxxxxx; dgdegra@xxxxxxxxxxxxx; keir@xxxxxxx >> Subject: Re: [PATCH v12 1/9] x86: add generic resource (e.g. MSR) access >> hypercall >> >> On 04/07/14 11:30, Jan Beulich wrote: >>>>>> On 04.07.14 at 11:40, <andrew.cooper3@xxxxxxxxxx> wrote: >>>> On 04/07/14 09:34, Dongxiao Xu wrote: >>>>> Add a generic resource access hypercall for tool stack or other >>>>> components, e.g., accessing MSR, port I/O, etc. >>>>> >>>>> Signed-off-by: Dongxiao Xu <dongxiao.xu@xxxxxxxxx> >>>> This still permits a user of the hypercalls to play with EFER or >>>> SYSENTER_EIP, which obviously is a very bad thing. >>>> >>>> There needs to be a whitelist of permitted MSRs which can be accessed. >>> Hmm, I'm not sure. One particular purpose I see here is to allow the >>> tool stack (or Dom0) access to MSRs Xen may not know about (yet). >>> Furthermore, this being a platform op, only the hardware domain >>> should ever have access, and it certainly ought to know what it's >>> doing. So the sum of these two considerations is: If at all, we may >>> want a black list here. >>> >>> Jan >>> >> I don't think it is safe for the toolstack to ever be playing with MSRs >> which Xen is completely unaware of. There is no guarentee whatsoever >> that a new MSR which Xen is unaware of doesn't have security >> implications if the toolstack were to play with it. >> >> Adding entries to a whitelist is easy and could be considered a >> maintenance activity similar to keeping the model/stepping information >> up-to-date. > This resource access mechanism is useful according to some conversation with > IPDC customers. Per their description, once the machine and VMs are online, > they will not be turned off. Sometimes administrators may need to dynamically > modify some resource values to fix/workaround certain issues, and our patch > may serve this purpose. > > Adding the white/black list will bring certain constraints for the above use > case. Also considering that the tool stack resides in dom0, I think it is not > so dangerous. The whole purpose of XSM is to split the toolstack up so it isn't all in dom0. Extending a whitelist is trivial, and requires a positive action on behalf of someone to decide that the added MSR *is* safe. Anything else is a security bug waiting to happen. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |