This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: "Tristan Gingold" <Tristan.Gingold@xxxxxxxx>, <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>, "Williamson, Alex (Linux Kernel Dev)" <alex.williamson@xxxxxx>
Subject: RE: [Xen-ia64-devel] RE: PATCH: merge iva
From: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
Date: Wed, 14 Jun 2006 09:48:12 -0700
Delivery-date: Wed, 14 Jun 2006 09:48:23 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <200606141008.03407.Tristan.Gingold@xxxxxxxx>
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcaPjQ9dUvy1ZXkOQu6pfFumFL4jdAAQ5G6A
Thread-topic: [Xen-ia64-devel] RE: PATCH: merge iva
> > 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

<Prev in Thread] Current Thread [Next in Thread>