Might add some checks or switch to a nop dispatch table in such cases or make
sure default window is never visible, anyway that's really a minor issue as we
don't want to behave exactly like a real gpu drivers here, for ex. like the
segfaults you've observed when a bound window was destroyed.
Agreed
The malicious program could simply guess at GL's CrWindow ID and send a
WindowDestroy; the server would then regard that as an out-of-thread destroy,
and zap gears' window...
Not really the case, window create/destroy ain't exported in the guest lib. At
the moment it's possible to getprocadress those functions but it could be
disabled. And if you'd talk about custom build app using lib sources...well
there're really easier ways to ruin host service in such case.
Heh, that's certainly true, and that's basically my problem here -- I'm
trying to implement a 3D layer which permits apps to draw without
allowing them to abuse other processes on the same or other VMs. That
you spawn a CrServer per VM stops the between-VMs case, but it certainly
seems as though Cr permits processes to do arbitrary violence upon one
another. I guess this is because Cr was built for remote rendering
between devices with common ownership, so protecting the server wasn't a
priority...
IDs sharing/quessing is really another issue. Some of those are not that easy
to separate, for example texture ids...it's valid to use *any* id which
application chooses, it might be a value returned by glGenTextures but not
necessary. So 1 client could really enumerate whole textures namespace if it
wants to.
Right, but that namespace is private per context, isn't it? If so, it's
enough that I can't bind the other guy's context to stop me from abusing
his textures.
Anyway there're plans to have separate host thread for every client opengl
thread, main reason though is to have a dedicated host opengl context per guest
context. At the same time it'd solve some of the IDs sharing issues.
Sounds like that would throw out a lot of Chromium, since half its
design was about minimising the state transition when multiplexing
renderers -- but then, I'd guess most graphics drivers would respond to
a MakeCurrent in similar fashion?
Aside from all that, I've another bug for you: guests sometimes issue a
WindowResize with zero width or height; the render SPU's GLX backend
translates that unthinkingly into an XResizeWindow, which kills the
server with an X error in that case. My solution was to unmap such
zero-area windows, setting a flag in their WindowInfo to note that
they're not really invisible, but hidden because their size is
unreasonable. Then I map them when a more sensible size is specified.
Chris
_______________________________________________
vbox-dev mailing list
[email protected]
http://vbox.innotek.de/mailman/listinfo/vbox-dev
