Describe the solution you'd like
Add a few functions that can be called in Lua to ICustomShape:
setShaderUniform(name: string, value: float or float[] or int or int[], type: "vec2" or "vec3" or "vec4" or "int" or "float" or "matrix2f" ... you get the idea): void or boolean[, string]
Apply shader uniform
name: Uniform name
value: Value of the uniform
type: Uniform type
Returns: Frist return value indicates if anything went wrong, and if something went wrong, the second return value will be the reason or error message
useShader(type: "FRAGMENT" or "VERTEX", source: string): boolean[, string]
Use a fragment or vertex shader to render the Custom shape. Whether the source is valid or not, it will still return true, and the compilation will be on the client-side, so if anything went wrong, it will only be logged on the client-side.
type: The type of the shader, can be fragment(FRAGMENT) or vertex(VERTEX)
source: The source of the shader.
Returns: First return value indicates if anything went wrong, and if something went wrong, the second return value will be the reason or error message
It would be very awesome, and it's easy to add (Although it requires updating commons0815's rendering toolkit - I mean if you want to implement it without updating commons0815's rendering toolkit, you can add apply the shader in the renderWidgets function), there will be (almost) no limitation of rendering stuff (except something like blurring background effect)
Describe alternatives you've considered
Well, if I'd like to listen to some GPU burning sound and see some fire on my PC, then I can render like 10000 triangles to do the gradient effect without a shader, but I'm not doing that lol.
Additional context
If there's no vertex shader, it will use this following default vertex shader that does nothing except passing the texture coord to fragment shader:
Add attributes: boolean shaderEnabled, String vertexShader, String fragmentShader, and somehow transfer the packets
When the client has gotten a packet with shader change and it's not already cached, it will compile it, and cache it into a hashmap with vertex.sha1() + fragment.sha1() as key, and the shader program itself as value.
When creating the shader program (the shader change) and it's not already cached, it will compile it, but if the compilation has failed, it will catch the exception, and send "Shader Compliation Failed" or something like that to the client side chat, and print the exception in the console [configurable - can be disabled]
If vertex shader is null, use the default shader I mentioned above
While rendering, checks if shaderEnabled && fragmentShader != null && fragmentShader.length() > 0
About the security:
""""""
I think the difficulty of successfully exploiting a machine through shaders is pretty difficult but not impossible or unprecedented.
Another vulnerability is that the shader could access other bits of graphics memory that are shared by the window manager or other applications, allowing it to perhaps be able to read the contents of your other windows. Exfiltration could be a stretch, but either low-quality drivers could allow the malicious shader to write to uncontrolled memory or you could use steganography to embed screenshots of other windows in the current game screenshots.
""""""
Describe the solution you'd like Add a few functions that can be called in Lua to ICustomShape:
setShaderUniform(name: string, value: float or float[] or int or int[], type: "vec2" or "vec3" or "vec4" or "int" or "float" or "matrix2f" ... you get the idea): void or boolean[, string] Apply shader uniform name: Uniform name value: Value of the uniform type: Uniform type Returns: Frist return value indicates if anything went wrong, and if something went wrong, the second return value will be the reason or error message
useShader(type: "FRAGMENT" or "VERTEX", source: string): boolean[, string] Use a fragment or vertex shader to render the Custom shape. Whether the source is valid or not, it will still return true, and the compilation will be on the client-side, so if anything went wrong, it will only be logged on the client-side. type: The type of the shader, can be fragment(
FRAGMENT
) or vertex(VERTEX
) source: The source of the shader. Returns: First return value indicates if anything went wrong, and if something went wrong, the second return value will be the reason or error messageIt would be very awesome, and it's easy to add (Although it requires updating commons0815's rendering toolkit - I mean if you want to implement it without updating commons0815's rendering toolkit, you can add apply the shader in the
renderWidgets
function), there will be (almost) no limitation of rendering stuff (except something like blurring background effect)Describe alternatives you've considered Well, if I'd like to listen to some GPU burning sound and see some fire on my PC, then I can render like 10000 triangles to do the gradient effect without a shader, but I'm not doing that lol.
Additional context If there's no vertex shader, it will use this following default vertex shader that does nothing except passing the texture coord to fragment shader:
If it's me, I'll implement it this way:
boolean shaderEnabled
,String vertexShader
,String fragmentShader
, and somehow transfer the packetsvertex.sha1() + fragment.sha1()
as key, and the shader program itself as value.shaderEnabled && fragmentShader != null && fragmentShader.length() > 0
About the security: """""" I think the difficulty of successfully exploiting a machine through shaders is pretty difficult but not impossible or unprecedented.
There's a small chance of that happening -- for example, there was an OSX vulnerability that enabled RCE or crashes http://www.cvedetails.com/cve/CVE-2016-1847/ but the vulnerability itself could be either from the GL library Memory safety errors in libGLES in the ANGLE graphics library or on the application side improperly handling bound buffer memory that could possibly be written to in the shader Buffer overflow in WebGL after out of memory allocation
Another vulnerability is that the shader could access other bits of graphics memory that are shared by the window manager or other applications, allowing it to perhaps be able to read the contents of your other windows. Exfiltration could be a stretch, but either low-quality drivers could allow the malicious shader to write to uncontrolled memory or you could use steganography to embed screenshots of other windows in the current game screenshots. """"""
Source: https://gamedev.stackexchange.com/questions/146278/could-executing-opengl-shaders-sent-from-a-server-be-dangerous