[Mesa-dev] [wip 0/9] GL_OES_get_program_binary extension

[Kenneth Graunke]

On 01/02/2014 03:58 AM, Tapani Pälli wrote:
> Hi;
> 
> Here's another take on the get_program_binary extension. I've rewritten big 
> chunks of it based on Paul's review and comments earlier. Here's a brief list 
> out of my head of things changed:
> 
> - uses mesa compilation time as verification method for cache, not git sha
> - much smaller serialization code size, now as part of IR classes
> - smaller binary blob size
> - does not dump separate 'prototypes block' for functions but instead
>  deserialization iterates over the whole blob for functions first
> - hashtables written faster than previously (iterated only once)
> - no 'unique_id' for ir_variables but using the address as identifier
> - patch set broken down to more individual patches/changes
> 
> Mesa branch with these patches applied on top:
> http://cgit.freedesktop.org/~tpalli/mesa/log/?h=oes_get_program_binary
> 
> I have plans for the addition of driver backend data but I was hoping this to 
> be as a separate addition on top. Basically I extend gl_shader_program struct 
> and offer API for drivers to dump their binary data there, some proto here:
> 
> http://cgit.freedesktop.org/~tpalli/mesa/log/?h=driver_interface
> (in order to work more data needed like the keys but this is just test)
> 
> I have also 'automatic' cache implementation here that can be used to verify 
> the cache functionality with any application (without extension):
> http://cgit.freedesktop.org/~tpalli/mesa/log/?h=new_serialization
> 
> Any comments appreciated;
> 
> Tapani Pälli (9):
>   glsl: memory_writer helper class for data serialization
>   glsl: serialize methods for IR instructions
>   glsl: memory_map helper class for data deserialization
>   glsl: add MESA_SHADER_CACHE_MAGIC string for shader binary cache
>   glsl: export populate_symbol_table function
>   glsl: ir_deserializer class for the binary shader cache
>   mesa: iterate method for string_to_uint_map
>   glsl: functions to serialize gl_shader and gl_shader_program
>   mesa: OES_get_program_binary extension functionality

Skimming through Paul's review comments...it sounds like there are a lot
of cases where your code has not handled invalid data gracefully.
That's not a critique of you or your code - there are a million cases to
consider, and it's really easy to miss one.

But, it sounds like there might be a lot of value in fuzz-testing this
extension (i.e. providing random data, or data with some structure but
invalid in specific places...).  We should probably be as mean as
possible in our testing up front to avoid security issues later.

--Ken