Kernel buffer overflow exposes iPhone 11 Pro to radio based attacks

H. S. Teoh hsteoh at quickfur.ath.cx
Wed Dec 9 01:43:45 UTC 2020


On Wed, Dec 09, 2020 at 01:23:37AM +0000, Paul Backus via Digitalmars-d wrote:
> On Tuesday, 8 December 2020 at 22:52:29 UTC, Dukc wrote:
[...]
> > 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.

IMO, if the module was reviewed, individual functions would be
annotated. I would not trust a "review" that simply slaps a blanket
@trusted on the top of the file.  Individually-annotated functions
increase my confidence that somebody has at least put in the effort to
look over each function.


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

Yeah, this is one of the main reasons there was a big backlash against
that DIP.


[...]
> 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?

Yeah, D's mantra all these years has always been, automatic verification
rather than programming by convention.  This DIP undermines that
principle.


T

-- 
Guns don't kill people. Bullets do.


More information about the Digitalmars-d mailing list