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


[Xen-devel] Is exposing shared_info to user-land secure?

To: "Xen-Devel (E-mail)" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] Is exposing shared_info to user-land secure?
From: "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx>
Date: Fri, 1 Aug 2008 10:13:39 -0600
Delivery-date: Fri, 01 Aug 2008 09:15:13 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Oracle Corporation
Reply-to: "dan.magenheimer@xxxxxxxxxx" <dan.magenheimer@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acjz8Y15ey1z2oZsTGWTFL6iUZbGKg==
Is it "safe" in a paravirtualized guest to expose shared_info
(at least read-only) to user-land?  That is, is there data
in shared_info that could be used by a malicious program to
compromise a guest OS (ignoring very complex side-channel
attacks anyway)?

We have apps that constantly do various time syscalls (e.g.
to gettimeofday()) and I'm thinking if vcpu_info(cpu)->time_info
was directly readable by an enterprise app, it could do
the time calculations itself and save the syscall overhead.



Thanks... for the memory
I really could use more / My throughput's on the floor
The balloon is flat / My swap disk's fat / I've OOM's in store
Overcommitted so much
(with apologies to the late great Bob Hope)
Xen-devel mailing list
<Prev in Thread] Current Thread [Next in Thread>