Kernel buffer overflow exposes iPhone 11 Pro to radio based attacks

Timon Gehr timon.gehr at gmx.ch
Wed Dec 9 18:20:48 UTC 2020


On 09.12.20 16:42, Dukc wrote:
> On Wednesday, 9 December 2020 at 13:25:49 UTC, Timon Gehr wrote:
>> On 09.12.20 12:46, Dukc wrote:
>>>
>>> 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.
>>
>> That's a bit like saying it's bad if products produced using slave 
>> labour don't get a fair trade label.
> 
> You're thinking `@safe` as a certificate.

It is, that's why it's on the function signature and causes function 
type incompatibility. `@safe` has an actual modular meaning that is 
communicated to the caller; it's not supposed to be just a collection of 
lint heuristics. It's supposed to contain all memory-safety errors 
within `@trusted` functions.

> It can definitely help in 
> doing certifying reviews, but it's also supposed to be a tool to catch 
> mistakes - for all code,

No, this feature does not exist currently, it is not the way @safe has 
been advertised, and separating code into @system/@trusted/@safe would 
make no sense if it was. You'd just want different strictness levels 
with no modular guarantees at all for most of them.

If that's useful to you, feel free to advocate for it, but this is not 
what `@safe` is.

> not just for code that wants to certify. That 
> it won't catch mistakes from using the C code does not prevent it from 
> catching other unrelated mistakes. That's still better than nothing if 
> we don't pretend that the C headers are certified.
> 
> One can still add a comment to describe why the code is annotated 
> `@safe` or `@trusted`.
> 

You can't have the documentation state one thing and silently start 
practicing the opposite. It's a plain, corrupt lie. Why is this not 
obvious? You'll be right back in fairy-tale wonderland where good 
programmers don't make mistakes and everyone else does not matter.


More information about the Digitalmars-d mailing list