Khronos Releases OpenGL 4.3 Specification with Major Enhancements | Hacker News Reader

Khronos Releases OpenGL 4.3 Specification with Major Enhancements

khronos.org

68 pointsTsiolkovsky13 comments

I noticed one bullet point:

"increased memory security that guarantees that an application cannot read or write outside its own buffers into another application’s data"

I don't know much about OpenGL, but would this address some of the WebGL security concerns?

It addresses a lot of concerns. A proper GL implementation should already do this correctly, Khronos is just mandating it as a requirement just to punish the few who don't get this correct.

WebGL is based on OpenGL ES, not OpenGL. (ES here stands for "embedded systems") Concurrently with OpenGL 4.3, Khronos also released OpenGL ES 3.0, the update for the spec which can reasonably expected to guide a later version of WebGL. On my reading, OpenGL ES 3.0 does not seem to require a comparable level of data safety.

The security aspects of the interaction between GPU code and HTML clients are all well-addressed by the current WebGL spec. Which particular concerns are you talking about?

One possibility where the new OpenGL 4.3 requirements might help is in current desktop WebGL implementations which translate WebGL (which is OpenGL ES) to OpenGL (the desktop). But WebGL is sometimes translated to OpenGL, sometimes to Direct3D via ANGLE, sometimes to OpenGL ES directly. Finally, relatively few desktop drivers actually implement the latest OpenGL spec anyway; OS X does not even have OpenGL 4.2 yet, despite being out for a long while now.

All this is to say that 1) I don't believe the new requirements will have no immediate impact on WebGL security and 2) WebGL buffer security is a non-issue (whether WebGL clients crash the video drivers or not is a different story).

When the last specs came out, nVidia had drivers implementing the specs on the same day and AMD a few days later.

If only all vendors adopted their drivers... (as I write from a Mac OS X 10.7 with an embarassingly old OpenGL implementation)

Well for example an uint32_t index buffer - it might contain indices that are outside of what's allowed. If the kernel/driver verifies this everytime, it might slow down somehow the operation. It's totally possible that the driver/chip somehow "clips" this, or being a bit of undefined operation - simply ignores it.

There might be other cases too.

WebGL mandates that the user agent check indices: http://www.khronos.org/registry/webgl/specs/latest/#ATTRIBS_...

As I alluded above, the current WebGL spec is actually fairly well-designed with respect to trying to crash display drivers.

The word "undefined" actually only appears once in the current spec, in a bit about canvas drawing buffers being preserved across frames. And, in fact, in that case it mandates implementations to clear the buffer before any WebGL call can read the contents to prevent leakage.

Most of the claims of WebGL security issues are either to old versions of the spec (which leaked data to shaders and led to things like timing attacks) or are currently a bit on the hyperbolic side.

I believe that the final bullet is the primary feature WebGL has been looking for:

"a multi-application robustness extension that ensures that an application that causes a GPU reset will not affect any other running applications."

AFAIK the only remaining WebGL security concerns are DoS related, where misbehaving content can crash your drivers. There are no currently known leaks of data.

Probably not. The overarching security concern with WebGL is that much of the complexity in e.g. compiling shaders or loading data into GPUs is happening in kernel code. A lot of it is driver dependent, so even if userland code gets everything right, there's a good chance that a sizable chunk of people are using drivers that aren't resilient against attacks. Finally, it is a lot easier to update a browser than it is to update a kernel video driver, and a decent chunk of the browser security model depends on browsers being automatically updated when vulnerabilities are discovered.

very useful summary:

http://www.anandtech.com/show/6134/khronos-announces-opengl-...

One of the main problems of previous texture compression methods like DXT2 was that they were encumbered in software patents.

This made implementing OpenGL in opensource quite problematic.

Does anyone know if this is also the case for ETC2 / EAC texture compression? I didn't really find any details on this.

Read the summary posted by bryanlarsen: https://news.ycombinator.com/item?id=4345768

Basically, ETC and ASTC are royalty-free parts of OpenGL.

naD Qo'noS Daq vam jaj

Reply on news.ycombinator.com