Kernel buffer overflow exposes iPhone 11 Pro to radio based attacks

[Dukc]

On Wednesday, 9 December 2020 at 01:23:37 UTC, Paul Backus wrote:
> 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.

Yes, this would be a problem, but I believe it'd be less of a 
problem than you think. If you use some third-party library, you 
need to think twice how much you trust it's `@safe`ty in any 
case. At least if you're that strict about it. No annotations 
anywhere is about the easiest thing to spot when considering that.

>
> 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?

It might have some benefit: If non-annotated C libraries are 
considered `@safe`, it'll mean that not-so-quality code is using 
compromised `@safe`. Bad. But if they are considered `@system`, 
not-so-quality code will not be using `@safe` AT ALL. Even worse.

Now I understand there is a drawback for higher-quality code. You 
have to either copy-paste the C library header and add `@system:` 
to top of it, or make a module that automatically wraps the 
header as `@system`. That's more work than just importing the C 
header, and thus will result in more greenwashed headers than C 
headers being `@system` by default.

Also it sure sucks that the compiler would do the wrong thing by 
default, but would the pragmatic downsides be even worse for the 
Common Sense option? I don't know, But I'm saying that 1: it's a 
judgement call, not anything absolute, 2: either way one could 
live with, and would be far from making `@safe` meaningless.