5 ms·

> That's not really a coupling issue, but a matter of GPU drivers not generally being hardened against shader/usage bugs. You shouldn't be able to crash the wh

> That's not really a coupling issue, but a matter of GPU drivers not generally being hardened against shader/usage bugs. You shouldn't be able to crash the whole operating system (not just the display server, display driver, etc.) with an ordinary shader, even if it crashes the shader compiler or causes the GPU not to halt. It's not as though I wrote these shaders in an attempt to crash iOS.

lagadu 7y ago
But that's unrelated to how tightly coupled the app is with the OS, but rather how ungracefully the driver fails. No matter how "far away" the app is from the gpu, at some point in the pipeline whatever data is being received will have to interact with it in some way, via the driver. Sure, you could patch the app to avoid sending what's known as bad data to the next layer but I'd argue that that's the wrong place to do it.
0x0 7y ago
That's not unique to iOS, though. It seems a lot of display drivers on a lot of platforms were developed without ever considering hostile shaders coming in over the network, in an era where mostly only game developers would catch crashes during development? For example https://chromium.googlesource.com/chromium/src/gpu/+/master/config/software_rendering_list.json https://chromium.googlesource.com/chromium/src/gpu/+/master/...
- microcolonel 7y ago
  Most of the software rendering list in Chromium is about more general bad behaviour, lack of features, or redundant behaviour (i.e. a GL driver is available, but it's a software renderer anyway, so might as well use Skia's software renderer), not security/full system DoS. For example, the one at id: 3 is for renderers with the lowercase word "software" in their name; id: 1 is a GPU which does not have enough features on its mac driver to run ANGLE for GLES 2.0 (and in turn WebGL 1); id: 5 is for very old versions of mesa, where the libGL would crash (which in practice means the application would crash, but not the display/windowing servers or the display driver, nor other applications). This behaviour on iOS is especially bad, it is not like other systems. The piece of code which would cause an issue like that is dramatically smaller on most Linux and Windows graphics stacks.
icebraining 7y ago
It might very well just be the OS's recovery procedure when the display server crashes, rather than an uncontrolled crash. It's not the phone is of much use without it, so might as well have a single booting procedure rather than trying to reboot subcomponents individually.
saagarjha 7y ago
On an iOS device crashing a critical component such as SpringBoard is often indistinguishable to the casual user from a reboot.

lagadu 7y ago

But that's unrelated to how tightly coupled the app is with the OS, but rather how ungracefully the driver fails. No matter how "far away" the app is from the gpu, at some point in the pipeline whatever data is being received will have to interact with it in some way, via the driver. Sure, you could patch the app to avoid sending what's known as bad data to the next layer but I'd argue that that's the wrong place to do it.

0x0 7y ago

That's not unique to iOS, though. It seems a lot of display drivers on a lot of platforms were developed without ever considering hostile shaders coming in over the network, in an era where mostly only game developers would catch crashes during development? For example https://chromium.googlesource.com/chromium/src/gpu/+/master/config/software_rendering_list.json https://chromium.googlesource.com/chromium/src/gpu/+/master/...

microcolonel 7y ago
Most of the software rendering list in Chromium is about more general bad behaviour, lack of features, or redundant behaviour (i.e. a GL driver is available, but it's a software renderer anyway, so might as well use Skia's software renderer), not security/full system DoS. For example, the one at id: 3 is for renderers with the lowercase word "software" in their name; id: 1 is a GPU which does not have enough features on its mac driver to run ANGLE for GLES 2.0 (and in turn WebGL 1); id: 5 is for very old versions of mesa, where the libGL would crash (which in practice means the application would crash, but not the display/windowing servers or the display driver, nor other applications). This behaviour on iOS is especially bad, it is not like other systems. The piece of code which would cause an issue like that is dramatically smaller on most Linux and Windows graphics stacks.

icebraining 7y ago

It might very well just be the OS's recovery procedure when the display server crashes, rather than an uncontrolled crash. It's not the phone is of much use without it, so might as well have a single booting procedure rather than trying to reboot subcomponents individually.

saagarjha 7y ago

On an iOS device crashing a critical component such as SpringBoard is often indistinguishable to the casual user from a reboot.