[vbox-dev] Chromium WindowDestroy

[Leonid]

Chris Smowton <cs448 at ...> writes:

> I just finished coding a similar solution, I'll see how our changes
> compare :)
> 
> In the course of doing so, I got to know the render SPU's "default
> window," which it creates at startup and uses to perform real-libGL
> MakeCurrents when the client hasn't sent us a WindowCreate yet, and the
> client might send GL commands which are legal without a current context
> (e.g. create/destroy-context) which on the server are executed using GL
> commands which *do* require a current context -- like the
> previous example with state_diff using glEnable and other state
> functions.
> 
> This looks like a minor problem -- a client could skip issuing a
> WindowCreate and start sending rendering commands, and the render SPU
> would map the default window. The default window is not a child of the
> VBox guest display window, so there would just be a random top-level
> window containing the guest's 3D content. It seems to me the guest
> shouldn't be able to "escape" its bounds like this, even cosmetically

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.

> A guest could run a regular GL program (say, gears,) and a malicious program.
> 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, which would then try to draw illegally -- and in fact,
> hit the default zero-window, according to your new fix. This seems to me as
> though it's allowing processes within one VM to violate the isolation which
> their operating system is supposed to provide. The same ID-guessing game
> could be played with contexts, and possibly other resources like textures (I
> haven't investigated how they're named by Cr yet). 

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.

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.

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.