Kernel buffer overflow exposes iPhone 11 Pro to radio based attacks

[Petar]

On Wednesday, 2 December 2020 at 15:19:37 UTC, IGotD- wrote:
> On Wednesday, 2 December 2020 at 15:13:35 UTC, Adam D. Ruppe 
> wrote:
>>
>> D range error actually doesn't allocate memory, it throws a 
>> statically allocated object, or with appropriate compile 
>> switches, calls an abort function directly.
>
> That's interesting and of course people don't this because it 
> is not documented and you of have study the source code in 
> detail to figure this out. Do we have a list what libraries use 
> statically allocated exceptions?

I haven't looked to find whether it's properly documented, but 
you can find the announcement about the feature that allows 
choosing the behavior here:

https://dlang.org/changelog/2.084.0.html#checkaction

As for how built-in error handling (I mean out-of-bounds array 
checks, out-of-memory, etc.) is implemented, it depends on 
whether betterC [1] is enabled and whether exception support is 
enabled [2].

[1]: 
https://github.com/dlang/druntime/blob/v2.094.2/src/core/exception.d#L22
[2]: 
https://github.com/dlang/druntime/blob/v2.094.2/src/core/exception.d#L16

If exception support is enabled, we do e.g.:

     throw staticError!RangeError(file, line, null);

(The last parameter is used for a chained exceptions, which here 
is not the case).

The implementation for staticError [3] uses a global TLS variable 
as storage, though I really don't know why it's implement more 
along the lines of this:

https://run.dlang.io/gist/PetarKirov/f7b6c3b7e4f8fe10c0a2dbf0d3f44471

[3]: 
https://github.com/dlang/druntime/blob/v2.094.2/src/core/exception.d#L634

Though I really think it should be implemented like this: