Unsuccessful glLinkProgram call behaviour

[null77]

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.

[null77]

More specifically I suggest we add errors to the draw commands that reject draws when the current program's last link call was unsuccessful.

[kenrussell]

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.

[kenrussell]

Note that this changes the behavior of conformance/programs/program-test.html in both the WebGL 1.0 and 2.0 conformance suites.

[kdashg]

This would be a breaking change. Hopefully very little content relies on it, but it's possible to implement, even on an untrusted driver.

[null77]

If any apps use it on Windows right now, they can crash in an unsafe way.