Unsuccessful glLinkProgram call behaviour
Opened this issue · 5 comments
The GLES spec says:
If that program object that is in use is re-linked unsuccessfully, the link status
will be set to FALSE, but existing executable and associated state will remain part
of the current rendering state until a subsequent call to UseProgram removes it
from use. After such a program is removed from use, it can not be made part of the
current rendering state until it is successfully re-linked.
ANGLE has ran into security problems with unsuccessful links, where our state objects become partially rewritten and use outdated link information. We should fireproof ANGLE, but seeing as there's a risk we could leave multiple hard-to-discover and potentially dangerous security holes I suggest we alter this wording to make WebGL reset the current installed executable when a program that is in-use is re-linked unsuccessfully.
More specifically I suggest we add errors to the draw commands that reject draws when the current program's last link call was unsuccessful.
Associated Chromium and ANGLE bugs for this issue are:
https://bugs.chromium.org/p/angleproject/issues/detail?id=6358
https://bugs.chromium.org/p/chromium/issues/detail?id=1241123
(restricted view, please ask me if you need access)
Let's discuss this during the next WebGL working group conference call. Agenda item has been added.
Note that this changes the behavior of conformance/programs/program-test.html in both the WebGL 1.0 and 2.0 conformance suites.
This would be a breaking change. Hopefully very little content relies on it, but it's possible to implement, even on an untrusted driver.
If any apps use it on Windows right now, they can crash in an unsafe way.