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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 14.02.17 at 18:33, <tim@xxxxxxx> wrote:
> Hi,
> 
> At 06:19 -0700 on 13 Feb (1486966797), Jan Beulich wrote:
>> The present way of setting this up is flawed: Leaving the I/O bitmap
>> pointer at zero means that the interrupt redirection bitmap lives
>> outside (ahead of) the allocated space of the TSS. Similarly setting a
>> TSS limit of 255 when only 128 bytes get allocated means that 128 extra
>> bytes may be accessed by the CPU during I/O port access processing.
>> 
>> Introduce a new HVM param to set the allocated size of the TSS, and
>> have the hypervisor actually take care of setting namely the I/O bitmap
>> pointer. Both this and the segment limit now take the allocated size
>> into account.
>> 
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> 
> This looks pretty good to me.  Once the question below is resolved,
> Reviewed-by: Tim Deegan <tim@xxxxxxx>
> 
>> ---
>> 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.

Jan


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