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

Re: [Xen-devel] [PATCH] x86/VMX: sanitize VM86 TSS handling



>>> On 16.02.17 at 12:14, <JBeulich@xxxxxxxx> wrote:
>>>> On 15.02.17 at 12:21, <tim@xxxxxxx> wrote:
>> At 01:18 -0700 on 15 Feb (1487121525), Jan Beulich wrote:
>>> >>> On 14.02.17 at 18:33, <tim@xxxxxxx> wrote:
>>> >> TBD: Do we really want to re-init the TSS every time we are about to
>>> >>      use it?
>>> > 
>>> > No - I think we should init it when the guest writes the param(s) and
>>> > leave it at that.  Hvmloader marks it as reserved so the guest should
>>> > know better than to write to it, and we can't protect it against all
>>> > the possible ways the guest could break itself.
>>> > 
>>> > If you do want to re-init it more often, then I think it would still
>>> > be better to legacy guests' (lack of a) size limit once, when the guest
>>> > writes the base param.
>>> 
>>> The only problem with this being that at the time the base gets
>>> written we don't know the size yet (nor whether the guest is
>>> going to write it), and hence we don't know how must space to
>>> initialize. The lower limit we enforce on the size (if being set) is
>>> below the 128 byte default for old guests.
>> 
>> Why not make the lower limit 128?  I'd happily exchange simpler
>> hypervisor code for the theoretical case of a guest that needs to run
>> realmode code and cares about those few bytes.
> 
> Actually there's one more issue with doing it when the parameter is
> being set: If a guest wanted to move the TSS (the parameter isn't
> one-shot after all), we can't use the old value of the other parameter
> when the first of the two is being changed. Of course we could make
> both parameters one-shot, but this would again seem arbitrary. So I
> think the better model is to record when either parameter changed,
> and do the initialization just once after that.

Actually no, this wouldn't work either, for the same reason (we might
again be using an inconsistent pair of parameters). Which makes me
come back to my original plan (not mentioned anywhere so far): 
Instead of a new size param, we need one which allows setting both
size and address at the same time. Since the address needs to be
below 4Gb anyway, we could simply use the high half of the 64-bit
value to hold the size.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

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