Xen devel - Aug 2008 - Is exposing shared_info to user-land secure?

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.

Comments?

Thanks,
Dan

==================================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
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

I think it might be okay. One issue is that how to let the user-space
process know what vcpu it is running on, so it can use the correct timestamp
info in a way that is safe against preemption. Bear in mind that the user
address space may be shared by multiple concurrent threads on different
VCPUs! If you assume consistent-tsc across all CPUs then the task is easier,
but I don''t think we''ll want to bake that assumption into
guest kernels and
their interface to user processes.

 -- Keir

On 1/8/08 17:13, "Dan Magenheimer" <dan.magenheimer@oracle.com>
wrote:
> 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.
> 
> Comments?
> 
> Thanks,
> Dan
> 
> ==================================> 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
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


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

Dan Magenheimer wrote:
> 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.
>   
You can use the HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_info, ) 
hypercall to move the vcpu structure out of the shared info structure; 
that could be placed somewhere mappable.  Though currently I use it to 
put it into the percpu data area for quick kernel access; it definitely 
wouldn''t be mappable by userspace there (well, not without padding it 
out to its own page, at least).

    J

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

Keir Fraser wrote:
> I think it might be okay. One issue is that how to let the user-space
> process know what vcpu it is running on, so it can use the correct
timestamp
> info in a way that is safe against preemption. Bear in mind that the user
> address space may be shared by multiple concurrent threads on different
> VCPUs! If you assume consistent-tsc across all CPUs then the task is
easier,
> but I don''t think we''ll want to bake that assumption into
guest kernels and
> their interface to user processes.
>   
x86-64 already exports the current cpu and nodeid in the limit of a gdt 
entry, so you can fetch it from userspace with lsl.

    J

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