This tracks a TODO from https://chromium-review.googlesource.com/c/chromium/src/+/514505.
In particular, the chromium raster extension doesn't validate that there are no other commands but raster between begin and end raster. piman lays out a few options in https://chromium-review.googlesource.com/c/chromium/src/+/514505/9/gpu/command_buffer/service/gles2_cmd_decoder.cc#20012
Copying and pasting from https://docs.google.com/document/d/1vsJsk1zGSagxxBggd8j5G9u0rMzD1NTaQWgEbUabEvY/edit?pli=1#heading=h.7mvk8x6esuk9
However, one thing that will need to be implemented is some way of preventing malicious clients from inserting commands that modify state in between begin/end raster chromium. One option is to add validation to all commands that it’s not in the middle of raster, but that seems like spreading this feature’s complexity into everything. Another option is to have two different decoders on the service side (both of which sharing the same gl context), and swap to the different decoder at begin raster and then back at end raster. The one downside to this is that the GrContext and its cache are not shared among all raster decoders even if they are in the same share group.
The best (but most work) option is to create a separate context for this work so that there’s no clobbering and no validation needed. This is piman’s “fourth thought” in the link above. Create a separate command buffer context that provides a different API to clients that can do both raster and resource management. From there, have all of these new raster decoders share the same gl context / gr context. State resetting is no longer needed and there’s no need to be defensive about inserting malicious commands in the middle of raster.
Design Doc: https://goo.gl/Q6E1ZC
This tracks a TODO from https://chromium-review.googlesource.com/c/chromium/src/+/514505.
In particular, the chromium raster extension doesn't validate that there are no other commands but raster between begin and end raster. piman lays out a few options in https://chromium-review.googlesource.com/c/chromium/src/+/514505/9/gpu/command_buffer/service/gles2_cmd_decoder.cc#20012
Copying and pasting from https://docs.google.com/document/d/1vsJsk1zGSagxxBggd8j5G9u0rMzD1NTaQWgEbUabEvY/edit?pli=1#heading=h.7mvk8x6esuk9
However, one thing that will need to be implemented is some way of preventing malicious clients from inserting commands that modify state in between begin/end raster chromium. One option is to add validation to all commands that it’s not in the middle of raster, but that seems like spreading this feature’s complexity into everything. Another option is to have two different decoders on the service side (both of which sharing the same gl context), and swap to the different decoder at begin raster and then back at end raster. The one downside to this is that the GrContext and its cache are not shared among all raster decoders even if they are in the same share group.
The best (but most work) option is to create a separate context for this work so that there’s no clobbering and no validation needed. This is piman’s “fourth thought” in the link above. Create a separate command buffer context that provides a different API to clients that can do both raster and resource management. From there, have all of these new raster decoders share the same gl context / gr context. State resetting is no longer needed and there’s no need to be defensive about inserting malicious commands in the middle of raster.
Comment 1 by vmi...@chromium.org
, Oct 30 2017NextAction: 2017-11-13
Owner: vmi...@chromium.org
Status: Assigned (was: Available)