How would you define bare-metal? WebGL is proxied via ANGLE, so there's no risk of crashing or other forms of leaky processes, which is typically the primary thing I think of when I worry about low-level APIs.
ANGLE is not a virtual machine but a translation layer from OpenGL ES (on which WebGL is based) to Direct3D. Inappropriate translation would result in a direct exploit unlike VM, since AFAIK there is no practical means to sandbox shaders. In some sense it is akin to JIT in a kernel which has the roughly same security ramification.
>Inappropriate translation would result in a direct exploit unlike VM, since AFAIK there is no practical means to sandbox shaders.
What does it mean to sandbox shaders in this context ? GL ES shaders are sent down in a high level language and can't really do much besides do computation on input parameters to generate output in a pipeline. I wish they were more general purpose and worthy of sandboxing but the web GL shaders are really limited.
First link demonstrates reading from uncleared buffered to capture screen contents - and is from Windows XP era.
Second one is about running a bitcoin miner on the GPU, hypothetical memory breaches, and GPU DoS. You can stall the graphics pipeline without shaders, run a miner on CPU, and I'm going to need a demonstration of a usefull GPU memory breach with WebGL. On top of that any such breach is likely driver dependent and will only work on some specific driver/HW combination - that's such a low attack surface I doubt anyone will bother developing exploits targeting that.
I didn't bother going through third because I wasted enough time on first and second, I don't see how anything here suggest you need to sandbox shaders.
Modern GPUs have process isolation just like CPUs, and if that is not enough for you, GPU APIs allow an application (in this case the browser) to request bounds-checked execution for extra safety.
ANGLE is used to to a source to source translation irrespective of backend - it normalizes the source input to various GPUs (dropping things that have historically been funky like comment parsing, #controls, dodgy constructs, disallowed constructs, etc)
[Source: I worked on the original spec and spent a lot of time trying to prevent the more egregious security and privacy problems]
... but Google Chrome is not running on game consoles anyways ? Blink likely can, but then it does not necessarily use ANGLE, e.g. for instance QtWebEngine definitely does not use ANGLE on Mac / Linux but does native GL calls instead.
I don't understand your point. Yes, it's using WebGL. Do you think that it's going to do WebGL -> OpenGL ES 2/3 calls -> ANGLE -> Direct3D -> PS4 graphics driver (like it does on e.g. chrome on windows) ? No, it's likely doing WebGL -> PS4 proprietary graphics API -> PS4 graphics driver, not going through ANGLE or whatnot
but why would it go through ANGLE's libGLESv2.so and add a backend to that for the PS4 when the PS4 team could most likely provide their own libGLESv2 which maps directly to their driver (since they were doing that already for the PS3) ? As this is what chrome actually calls, gles functions.
Unless I missed something, when were they doing that with PS3?
The only effort to do any GL like stuff was on the PS2, with GL ES 1.0 + Cg, an effort that was dropped when almost no dev cared to use it.
Other than that there was the PSGL library for PS2 Linux.
Anyway, I did a bit more research and Chrome was actually only used for development purposes, they created their own WebGL engine on top of PhyreEngine for the console OS.
Regardless of how you define bare-metal, OP has a point here. Besides from bespoke web applications (which should be fully packages and signed, btw.), execution of turing-complete code inside the browser is pointless. At best, it helps to workaround certain limitations (bandwidth, browser quirks), or proves the UX of a page. But mostly it is just getting in the way or outright used against the user.
