Kernel buffer overflow exposes iPhone 11 Pro to radio based attacks

[Adam D. Ruppe]

On Wednesday, 2 December 2020 at 15:19:37 UTC, IGotD- wrote:
> That's interesting and of course people don't this because it 
> is not documented

It is documented that catching an Error will not necessarily 
work. This is meant to give significant freedom to the 
implementation.

Note that Error and Exception are two different things. Both are 
thrown and sometimes caught, but they are two different branches 
of classes and the language definition treats them differently. 
Exceptions are meant to be caught and unwind the stack as they 
work their way up it. Errors are meant to kill the program and 
thus may or may not unwind the stack and be allowed to be caught. 
(the `-checkaction` switch to dmd can change throw Error to 
simply abort the program by a couple means)

> Do we have a list what libraries use statically allocated 
> exceptions?

Library exceptions are free to do this too, but they usually 
don't since user code is permitted to catch and even retain 
references to normal exception objects. So it makes it difficult 
to use tricks like this without breaking user code.

But if a specific library were to do it, it would surely be 
documented and specially called out for them. No list as far as I 
know though.

> Then comes the question, how is this statically allocated 
> exception placed, on stack or TLS.

It is implementation defined, so a kernel implementation would 
surely do it differently if necessary, but in the default impl it 
goes in TLS. There's one block it reuses for any Error that 
occurs.

Most common examples of Errors are RangeError for out-of-bounds 
array access and AssertError for failed assertions.

> Is it shared with all libraries that throws RangeError or is it 
> per library?

This is part of druntime, so unless your libraries have multiple 
copies of the runtime (which is possible with Windows dlls but 
not really anywhere else, the system linker will merge the 
definitions) there's just the one.

If some library decides to `throw new RangeError` of course that 
would be an ordinary GC'd object. The language doesn't prohibit 
this but it also doesn't allow it per se, it is still subject to 
the implementation's whim.