Kernel buffer overflow exposes iPhone 11 Pro to radio based attacks

[Paul Backus]

On Tuesday, 8 December 2020 at 22:52:29 UTC, Dukc wrote:
> On Sunday, 6 December 2020 at 04:52:19 UTC, Bruce Carneal wrote:
>> Even though I love working on projects that should operate 
>> near HW limits, I would like to see defaults favor newcomers 
>> and prototyping (@safe, throw, gc).
>>
>> 1028 without the "C is @safe" falsehood could work.
>
> Consider a module with `@safe:` or `@trusted:` at top. The 
> problem with the rule "external C functions can't be @safe" or 
> "can't be @safe by default" is that you do not know why the 
> annotation is at the top of module. It could be because it has 
> been reviewed, or it could be just to get functions calling it 
> to quickly work.
>
> Theoretically, if C code is considered `@safe` by default, you 
> can tell them from each other. No attributes: `@system`, but 
> considered `@safe` for now, meaning you want to review the 
> module in the near future. `@safe` or `@trusted`: someone has 
> checked the module, nothing to worry about.

The problem with this is that there is existing *correct* D code 
that relies "no attributes" meaning @system, and which would 
silently become incorrectly-annotated if the default were 
changed. For example, there are many external @system functions 
in the D runtime that do not have an explicit @system annotation.

You flip the switch, your tests pass, and then months or years 
later, you discover that a memory-corruption bug has snuck its 
way into your @safe code, because no one ever got around to 
putting an explicit @system annotation on some external function 
deep in one of your dependencies. How would you react? 
Personally, I'd jump ship to Rust and never look back.

Of course, you can try to argue that it's the fault of the 
library maintainer for not realizing that they need to re-review 
all of their external function declarations--but why should they 
have to, when the compiler can just as easily flag those 
functions automatically? Isn't the whole reason we have automatic 
memory-safety checks in the first place to *avoid* relying on 
programmer discipline for this kind of thing?