[vbox-dev] Chromium WindowDestroy

[Chris Smowton]

> 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