RE: [Xen-ia64-devel] RE: PATCH: merge iva

["Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>]

> > If the guest could randomly (maliciously or accidentally)
> > change iva, Xen should re-validate it before using it (e.g.
> > to ensure that it is not in Xen address space, to ensure
> > it is not an I/O address etc.)
> As you noticed, these checks are not performed.
> Xen address space is protected with PL.  So even if guest 
> sets iva to Xen 
> address space, Xen won't crash.
> IA64 doesn't do any checks on IVA.  Why Xen/ia64 should do checks ?

IA64 *does* do "checks".  The low order 15 bits are ignored
and "processor behavior is unpredictable" if an unimplemented
virtual address is used.
 
> >  By allowing it to be changed
> > only via the privileged instruction (trapped/emulated), it
> > need only be validated when set (once at boot time for Linux).
> 
> > I realize validation may not be fully implemented (and there may
> > be some registers in the wrong place), but that's the intent.
> I fully agree, but I don't understand what checks you'd like to see 
> implemented.

Hmmm...  Perhaps when vcr.iva is set, the low 15 bits
should be zeroed.  Also, maybe it should be checked for a
valid virtual address, though post-Merced I don't think there
are any Itanium processors that don't use all 64 VA bits.
 
> I won't fight for this patch.  I just think it cleans 
> Xen/ia64 a little bit 
> (avoid useless VMX_DOMAIN tests), and simplify a little bit 
> save&restore
> (iva don't have to be in the vcpu_context).

I wasn't fighting the specific patch as much as providing
history.  The possibility of vcr.iva being used maliciously
is very small but vBlades evolved from a security-focused
project so validating all privileged registers to eliminate
security holes was an early vBlades objective.  To contrive
an example, if an attacker could somehow change vcr.iva,
he might be able to cause arbitrary user code to be executed
at PL2.


_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel