[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH RFC v1 40/74] xen/x86: report domain id on cpuid

>>> On 08.01.18 at 12:22, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 08/01/18 11:11, Jan Beulich wrote:
>>>>> On 08.01.18 at 11:34, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> On 08/01/18 10:27, Jan Beulich wrote:
>>>>>>> On 04.01.18 at 14:05, <wei.liu2@xxxxxxxxxx> wrote:
>>>>> From: Roger Pau Monne <roger.pau@xxxxxxxxxx>
>>>>> Use the ebx register of the hypervisor leaf 1. The eax register on
>>>>> this leaf is already used to report the Xen major and minor versions.
>>>> The rationale for doing this is missing. Iirc in past discussions the
>>>> opinion was voiced (more than once, and iirc by Andrew any maybe
>>>> others) that a domain in general shouldn't be told about its domain
>>>> ID. Otherwise I also can't see why we don't have a hypercall for
>>>> this, and e.g. XTF needs to go through hoops to figure it out. Are
>>>> those arguments (which I don't recall) not applicable anymore?
>>>> In the Amazon shim patches thread handing out the domain ID by
>>>> command line option was suggested as an alternative, which then
>>>> wouldn't affect other (non-shim) domains, or the client of the shim.
>>> A guests domid is unconditionally always available in xenstore, and is a
>>> necessary part of any PV communication.
>>> Like it or not, domid is part of the guests view of the Xen ABI. 
>>> Therefore, making it easily accessible is the best course of action
>>> (especially as pv-shim deliberately doesn't interpose on the xenstore ring).
>> All understood, yet you don't address the question on the
>> backgrounds of the change of your opinion here. Or am I
>> misremembering that earlier on you were against exposing
>> the domain ID?
> In the past, I was concerned about how a guest can brute force its own
> domid via leaky error conditions in some hypercalls.  I still think
> these should be fixed.

I agree on that latter part.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.