Bugzilla

I think it is inaccurate to say that we are circumventing the sandbox from the GPU process, for the reason that the GPU process is not enabled on all platforms or for all users.

Only half our platforms do not have it by default, and on those platforms that do, we don't always guarantee the user even gets it to start with. So for a sizeable portion of our users, there is no sandbox beyond the separation of content and parent process.

The GPU process was intended to defend against drivers that are intermittently buggy, so that the GPU can go down without taking out the parent process and with it the entire browser. For drivers that are so indefensibly buggy that it makes no sense to continue acceleration, we allow the acceleration to fall back to software rendering outside the GPU process.

The other side intention to it was to move privileged access to move some OS APi access out of the content process (i.e. Win32).

The architecture wasn't really meant to work as an isolation mechanism in the way that content processes isolate from parent.

Right now there are many assumptions built into the very core of Gecko that of you have the GPU process you get acceleration, but if you don't have acceleration, we must disable the GPU process to provide that fallback.

This assumption makes sense for a fallback in that fallback/software Canvas rendering actually takes place in the content process; it does not suddenly happen in the parent process, so if anything, the "sandbox", or at least the isolation between parent and content processes, is partially strengthened, not weakened, when the GPU process goes away. 

This falls down for WebRender in that we still remote that to the parent when the GPU process isn't available. Here is where the problem really lies.

I don't know that we have adequately addressed all the performance assumptions of doing software fallback rendering and composition for WebRender within the GPU process.

And we would still need to move into a world where all platforms and users get the GPU process for this to be make sense rather than have the GPU process only intermittently available by default.

I think it is inaccurate to say that we are circumventing the sandbox from the GPU process, for the reason that the GPU process is not enabled on all platforms or for all users.

Only half our platforms do not have it by default, and on those platforms that do, we don't always guarantee the user even gets it to start with. So for a sizeable portion of our users, there is no sandbox beyond the separation of content and parent process.

The GPU process was intended to defend against drivers that are intermittently buggy, so that the GPU can go down without taking out the parent process and with it the entire browser. For drivers that are so indefensibly buggy that it makes no sense to continue acceleration, we allow the acceleration to fall back to software rendering outside the GPU process.

The other side intention to it was to move privileged access to move some OS APi access out of the content process (i.e. Win32).

The architecture wasn't really meant to work as an isolation mechanism in the way that content processes isolate from parent.

Right now there are many assumptions built into the very core of Gecko that of you have the GPU process you get acceleration, but if you don't have acceleration, we must disable the GPU process to provide that fallback.

This assumption makes sense for a fallback in that fallback/software Canvas rendering actually takes place in the content process; it does not suddenly happen in the parent process, so if anything, the "sandbox", or at least the isolation between parent and content processes, is partially strengthened, not weakened, when the GPU process goes away. 

This falls down for WebRender in that we still remote that to the parent when the GPU process isn't available. The same problem is also true of WebGL. Due to moving OS API access out of the content processes, we have no choice but to use the parent process for these sensitive tasks when there is no GPU process possible. Here is where the problem really lies.

I don't know that we have adequately addressed all the performance assumptions of doing software fallback rendering and composition for WebRender within the GPU process.

And we would still need to move into a world where all platforms and users get the GPU process for this to be make sense rather than have the GPU process only intermittently available by default.

I think it is inaccurate to say that we are circumventing the sandbox from the GPU process, for the reason that the GPU process is not enabled on all platforms or for all users.

Only half our platforms do not have it by default, and on those platforms that do, we don't always guarantee the user even gets it to start with. So for a sizeable portion of our users, there is no sandbox beyond the separation of content and parent process.

The GPU process was intended to defend against drivers that are intermittently buggy, so that the GPU can go down without taking out the parent process and with it the entire browser. For drivers that are so indefensibly buggy that it makes no sense to continue acceleration, we allow the acceleration to fall back to software rendering outside the GPU process.

The other side intention to it was to move privileged access to move some OS API access out of the content process (i.e. Win32). However, it was more of a side intention that this happened to move it to the GPU process sometimes, if not the parent process.

The architecture wasn't really meant to work as an isolation mechanism in the way that content processes isolate from parent, more about the intermittent bugginess of drivers not taking down the browser.

Right now there are many assumptions built into the very core of Gecko that of you have the GPU process you get acceleration, but if you don't have acceleration, we must disable the GPU process to provide that fallback.

This assumption makes sense for a fallback in that fallback/software Canvas rendering actually takes place in the content process; it does not suddenly happen in the parent process, so if anything, the "sandbox", or at least the isolation between parent and content processes, is partially strengthened, not weakened, when the GPU process goes away. 

This falls down for WebRender in that we still remote that to the parent when the GPU process isn't available. The same problem is also true of WebGL. Due to moving OS API access out of the content processes, we have no choice but to use the parent process for these sensitive tasks when there is no GPU process possible. Here is where the problem really lies.

I don't know that we have adequately addressed all the performance assumptions of doing software fallback rendering and composition for WebRender within the GPU process.

And we would still need to move into a world where all platforms and users get the GPU process for this to be make sense rather than have the GPU process only intermittently available by default.

I think it is inaccurate to say that we are circumventing the sandbox from the GPU process, for the reason that the GPU process is not enabled on all platforms or for all users.

Only half our platforms do not have it by default, and on those platforms that do, we don't always guarantee the user even gets it to start with. So for a sizeable portion of our users, there is no sandbox beyond the separation of content and parent process.

The GPU process was intended to defend against drivers that are intermittently buggy, so that the GPU can go down without taking out the parent process and with it the entire browser. For drivers that are so indefensibly buggy that it makes no sense to continue acceleration, we allow the acceleration to fall back to software rendering outside the GPU process.

The other side intention to it was to move privileged access to move some OS API access out of the content process (i.e. Win32). However, it was more of a side intention that this happened to move it to the GPU process sometimes, if not the parent process.

The architecture wasn't really meant to work as an isolation mechanism in the way that content processes isolate from parent, more about the intermittent bugginess of drivers not taking down the browser.

Right now there are many assumptions built into the very core of Gecko that of you have the GPU process you get acceleration, but if you don't have acceleration, we must disable the GPU process to provide that fallback.

This assumption makes sense for a fallback in that fallback/software Canvas rendering actually takes place in the content process; it does not suddenly happen in the parent process, so if anything, the "sandbox", or at least the isolation between parent and content processes, is partially strengthened, not weakened, when the GPU process goes away. 

This falls down for WebRender in that we still remote that to the parent when the GPU process isn't available. The same problem is also true of WebGL. Due to moving OS API access out of the content processes, we have no choice but to use the parent process for these sensitive tasks when there is no GPU process possible. Here is where the problem really lies.

I don't know that we have adequately addressed all the performance assumptions of doing software fallback rendering and composition for WebRender within the GPU process.

And we would still need to move into a world where all platforms and users get the GPU process for this to be make sense rather than have the GPU process only intermittently available by default.

I say all this to point out that what we are discussing here is not actually a "bug" on the GPU process design. We are instead discussing how to rearchitect the GPU process into something else that it wasn't entirely intended to be, which isn't impossible, but not a simple fix.

I think it is inaccurate to say that we are circumventing the sandbox from the GPU process, for the reason that the GPU process is not enabled on all platforms or for all users.

Half our platforms do not have it by default, and on those platforms that do, we don't always guarantee the user even gets it to start with. So for a sizeable portion of our users, there is no sandbox beyond the separation of content and parent process.

The GPU process was intended to defend against drivers that are intermittently buggy, so that the GPU can go down without taking out the parent process and with it the entire browser. For drivers that are so indefensibly buggy that it makes no sense to continue acceleration, we allow the acceleration to fall back to software rendering outside the GPU process.

The other side intention to it was to move privileged access to move some OS API access out of the content process (i.e. Win32). However, it was more of a side intention that this happened to move it to the GPU process sometimes, if not the parent process.

The architecture wasn't really meant to work as an isolation mechanism in the way that content processes isolate from parent, more about the intermittent bugginess of drivers not taking down the browser.

Right now there are many assumptions built into the very core of Gecko that of you have the GPU process you get acceleration, but if you don't have acceleration, we must disable the GPU process to provide that fallback.

This assumption makes sense for a fallback in that fallback/software Canvas rendering actually takes place in the content process; it does not suddenly happen in the parent process, so if anything, the "sandbox", or at least the isolation between parent and content processes, is partially strengthened, not weakened, when the GPU process goes away. 

This falls down for WebRender in that we still remote that to the parent when the GPU process isn't available. The same problem is also true of WebGL. Due to moving OS API access out of the content processes, we have no choice but to use the parent process for these sensitive tasks when there is no GPU process possible. Here is where the problem really lies.

I don't know that we have adequately addressed all the performance assumptions of doing software fallback rendering and composition for WebRender within the GPU process.

And we would still need to move into a world where all platforms and users get the GPU process for this to be make sense rather than have the GPU process only intermittently available by default.

I say all this to point out that what we are discussing here is not actually a "bug" on the GPU process design. We are instead discussing how to rearchitect the GPU process into something else that it wasn't entirely intended to be, which isn't impossible, but not a simple fix.

I think it is inaccurate to say that we are circumventing the sandbox from the GPU process, for the reason that the GPU process is not enabled on all platforms or for all users.

Half our platforms do not have it by default, and on those platforms that do, we don't always guarantee the user even gets it to start with. So for a sizeable portion of our users, there is no sandbox beyond the separation of content and parent process.

The GPU process was intended to defend against drivers that are intermittently buggy, so that the GPU can go down without taking out the parent process and with it the entire browser. For drivers that are so indefensibly buggy that it makes no sense to continue acceleration, we allow the acceleration to fall back to software rendering outside the GPU process.

The other side intention to it was to move privileged access to move some OS API access out of the content process (i.e. Win32). However, it was more of a side intention that this happened to move it to the GPU process sometimes, if not the parent process.

The architecture wasn't really meant to work as an isolation mechanism in the way that content processes isolate from parent, more about the intermittent bugginess of drivers not taking down the browser.

Right now there are many assumptions built into the very core of Gecko that if you have the GPU process you get acceleration, but if you don't have acceleration, we must disable the GPU process to provide that fallback.

This assumption makes sense for a fallback in that fallback/software Canvas rendering actually takes place in the content process; it does not suddenly happen in the parent process, so if anything, the "sandbox", or at least the isolation between parent and content processes, is partially strengthened, not weakened, when the GPU process goes away. 

This falls down for WebRender in that we still remote that to the parent when the GPU process isn't available. The same problem is also true of WebGL, that can't operate in the content process either. Due to moving OS API access out of the content processes, we have no choice but to use the parent process for these sensitive tasks when there is no GPU process possible. Here is where the problem really lies.

I don't know that we have adequately addressed all the performance assumptions of doing software fallback rendering and composition for WebRender within the GPU process.

And we would still need to move into a world where all platforms and users get the GPU process for this to be make sense rather than have the GPU process only intermittently available by default. That is tricky on some platforms.

I say all this to point out that what we are discussing here is not actually a "bug" on the GPU process design. We are instead discussing how to rearchitect the GPU process into something else that it wasn't entirely intended to be, which is conceivably possible, but not a simple fix.

I think it is inaccurate to say that we are circumventing the sandbox from the GPU process, for the reason that the GPU process is not enabled on all platforms or for all users.

Half our platforms do not have it by default, and on those platforms that do, we don't always guarantee the user even gets it to start with. So for a sizeable portion of our users, there is no sandbox beyond the separation of content and parent process.

The GPU process was intended to defend against drivers that are intermittently buggy, so that the GPU can go down without taking out the parent process and with it the entire browser. For drivers that are so indefensibly buggy that it makes no sense to continue acceleration, we allow the acceleration to fall back to software rendering outside the GPU process.

The other side intention to it was to move privileged access to some OS API access out of the content process (i.e. Win32). However, it was more of an unintentional benefit that this happened to move it to the GPU process sometimes, if not the parent process.

The architecture wasn't really meant to work as an isolation mechanism in the way that content processes isolate from parent, more about the intermittent bugginess of drivers not taking down the browser.

Right now there are many assumptions built into the very core of Gecko that if you have the GPU process you get acceleration, but if you don't have acceleration, we must disable the GPU process to provide that fallback.

This assumption makes sense for a fallback in that fallback/software Canvas rendering actually takes place in the content process; it does not suddenly happen in the parent process, so if anything, the "sandbox", or at least the isolation between parent and content processes, is partially strengthened, not weakened, when the GPU process goes away. 

This falls down for WebRender in that we still remote that to the parent when the GPU process isn't available. The same problem is also true of WebGL, that can't operate in the content process either. Due to moving OS API access out of the content processes, we have no choice but to use the parent process for these sensitive tasks when there is no GPU process possible. Here is where the problem really lies.

I don't know that we have adequately addressed all the performance assumptions of doing software fallback rendering and composition for WebRender within the GPU process.

And we would still need to move into a world where all platforms and users get the GPU process for this to be make sense rather than have the GPU process only intermittently available by default. That is tricky on some platforms.

I say all this to point out that what we are discussing here is not actually a "bug" on the GPU process design. We are instead discussing how to rearchitect the GPU process into something else that it wasn't entirely intended to be, which is conceivably possible, but not a simple fix.

I think it is inaccurate to say that we are circumventing the sandbox from the GPU process, for the reason that the GPU process is not enabled on all platforms or for all users.

Half our platforms do not have it by default, and on those platforms that do, we don't always guarantee the user even gets it to start with. So for a sizeable portion of our users, there is no sandbox beyond the separation of content and parent process.

The GPU process was intended to defend against drivers that are intermittently buggy, so that the GPU can go down without taking out the parent process and with it the entire browser. For drivers that are so indefensibly buggy that it makes no sense to continue acceleration, we allow the acceleration to fall back to software rendering outside the GPU process.

The other side intention to it was to move privileged access to some OS API access out of the content process (i.e. Win32). However, it was more of an unintentedbenefit that this happened to move it to the GPU process sometimes, if not the parent process.

The architecture wasn't really meant to work as an isolation mechanism in the way that content processes isolate from parent, more about the intermittent bugginess of drivers not taking down the browser.

Right now there are many assumptions built into the very core of Gecko that if you have the GPU process you get acceleration, but if you don't have acceleration, we must disable the GPU process to provide that fallback.

This assumption makes sense for a fallback in that fallback/software Canvas rendering actually takes place in the content process; it does not suddenly happen in the parent process, so if anything, the "sandbox", or at least the isolation between parent and content processes, is partially strengthened, not weakened, when the GPU process goes away. 

This falls down for WebRender in that we still remote that to the parent when the GPU process isn't available. The same problem is also true of WebGL, that can't operate in the content process either. Due to moving OS API access out of the content processes, we have no choice but to use the parent process for these sensitive tasks when there is no GPU process possible. Here is where the problem really lies.

I don't know that we have adequately addressed all the performance assumptions of doing software fallback rendering and composition for WebRender within the GPU process.

And we would still need to move into a world where all platforms and users get the GPU process for this to be make sense rather than have the GPU process only intermittently available by default. That is tricky on some platforms.

I say all this to point out that what we are discussing here is not actually a "bug" on the GPU process design. We are instead discussing how to rearchitect the GPU process into something else that it wasn't entirely intended to be, which is conceivably possible, but not a simple fix.

I think it is inaccurate to say that we are circumventing the sandbox from the GPU process, for the reason that the GPU process is not enabled on all platforms or for all users.

Half our platforms do not have it by default, and on those platforms that do, we don't always guarantee the user even gets it to start with. So for a sizeable portion of our users, there is no sandbox beyond the separation of content and parent process.

The GPU process was intended to defend against drivers that are intermittently buggy, so that the GPU can go down without taking out the parent process and with it the entire browser. For drivers that are so indefensibly buggy that it makes no sense to continue acceleration, we allow the acceleration to fall back to software rendering outside the GPU process.

The other side intention to it was to move privileged access to some OS API access out of the content process (i.e. Win32). However, it was more of an unintentedbenefit that this happened to move it to the GPU process sometimes, if not the parent process.

The architecture wasn't really meant to work as an isolation mechanism in the way that content processes isolate from parent, more about the intermittent bugginess of drivers not taking down the browser.

Right now there are many assumptions built into the very core of Gecko that if you have the GPU process you get acceleration, but if you don't have acceleration, we must disable the GPU process to provide that fallback.

This assumption makes sense for a fallback in that fallback/software Canvas rendering actually takes place in the content process; it does not suddenly happen in the parent process, so if anything, the "sandbox", or at least the isolation between parent and content processes, is partially strengthened, not weakened, when the GPU process goes away. 

This falls down for WebRender in that we still remote that to the parent when the GPU process isn't available. The same problem is also true of WebGL, that can't operate in the content process either. Due to moving OS API access out of the content processes, we have no choice but to use the parent process for these sensitive tasks when there is no GPU process possible. Here is where the problem really lies.

I don't know that we have adequately addressed all the performance assumptions of doing software fallback rendering and composition for WebRender within the GPU process.

And we would still need to move into a world where all platforms and users get the GPU process for this to be make sense rather than have the GPU process only intermittently available by default. That is tricky on some platforms.

I say all this to point out that what we are discussing here is not actually a "bug"ion the GPU process design. We are instead discussing how to rearchitect the GPU process into something else entirely which is conceivably possible, but not a simple fix.

I think it is inaccurate to say that we are circumventing the sandbox from the GPU process, for the reason that the GPU process is not enabled on all platforms or for all users.

Half our platforms do not have it by default, and on those platforms that do, we don't always guarantee the user even gets it to start with. So for a sizeable portion of our users, there is no sandbox beyond the separation of content and parent process.

The GPU process was intended to defend against drivers that are intermittently buggy, so that the GPU can go down without taking out the parent process and with it the entire browser. For drivers that are so indefensibly buggy that it makes no sense to continue acceleration, we allow the acceleration to fall back to software rendering outside the GPU process.

The other side intention to it was to move privileged access to some OS API access out of the content process (i.e. Win32). However, it was more of an unintended benefit that this happened to move it to the GPU process sometimes, if not the parent process.

The architecture wasn't really meant to work as an isolation mechanism in the way that content processes isolate from parent, more about the intermittent bugginess of drivers not taking down the browser.

Right now there are many assumptions built into the very core of Gecko that if you have the GPU process you get acceleration, but if you don't have acceleration, we must disable the GPU process to provide that fallback.

This assumption makes sense for a fallback in that fallback/software Canvas rendering actually takes place in the content process; it does not suddenly happen in the parent process, so if anything, the "sandbox", or at least the isolation between parent and content processes, is partially strengthened, not weakened, when the GPU process goes away. 

This falls down for WebRender in that we still remote that to the parent when the GPU process isn't available. The same problem is also true of WebGL, that can't operate in the content process either. Due to moving OS API access out of the content processes, we have no choice but to use the parent process for these sensitive tasks when there is no GPU process possible. Here is where the problem really lies.

I don't know that we have adequately addressed all the performance assumptions of doing software fallback rendering and composition for WebRender within the GPU process.

And we would still need to move into a world where all platforms and users get the GPU process for this to be make sense rather than have the GPU process only intermittently available by default. That is tricky on some platforms.

I say all this to point out that what we are discussing here is not actually a "bug"ion the GPU process design. We are instead discussing how to rearchitect the GPU process into something else entirely which is conceivably possible, but not a simple fix.