Typical security issues in C++: why the GC isn't your enemy

[Siarhei Siamashka]

On Tuesday, 13 December 2022 at 01:35:48 UTC, areYouSureAboutThat 
wrote:
> On Tuesday, 13 December 2022 at 00:56:12 UTC, Siarhei Siamashka 
> wrote:
>> On Monday, 12 December 2022 at 23:48:58 UTC, 
>> areYouSureAboutThat wrote:
>>> So how about a compile time, commandline switch, that (warns 
>>> or fails) when @safe code is calling @trusted code?
>>>
>>> Basically, I'm, saying to the compiler -> "if it's not @safe, 
>>> I do not 'trust' it."
>>
>> Then you will have this warning in pretty much every 
>> application. Because any @safe code eventually ends up doing 
>> OS kernel API calls to show stuff on your screen or save it to 
>> a hard drive. The bridge from @safe to @system has to be 
>> crossed somewhere and the code annotated as @trusted works as 
>> such bridge.
>>
>
> you mean like this:
>
> https://learn.microsoft.com/en-us/dotnet/csharp/misc/cs0227

I mean like this:

```D
import std.stdio;
void main() @safe {
   writeln("Hello, world!");
}
```

```
$ dmd -g hello.d
$ gdb ./hello
(gdb) b write
(gdb) r
Breakpoint 1, 0x00007ffff7714bb0 in write () from /lib64/libc.so.6

(gdb) bt
#0  0x00007ffff7714bb0 in write () from /lib64/libc.so.6
#1  0x00007ffff7699ecd in _IO_file_write@@GLIBC_2.2.5 () from 
/lib64/libc.so.6
#2  0x00007ffff7699256 in new_do_write () from /lib64/libc.so.6
#3  0x00007ffff769af69 in __GI__IO_do_write () from 
/lib64/libc.so.6
#4  0x00007ffff769b393 in __GI__IO_file_overflow () from 
/lib64/libc.so.6
#5  0x0000555555557110 in 
std.stdio.File.LockingTextWriter.put!(char).put(char)
#6  0x00005555555563a0 in 
std.stdio.writeln!(immutable(char)[]).writeln(immutable(char)[])
#7  0x00005555555562e0 in D main () at ./hello.d:3

(gdb) disassemble
Dump of assembler code for function write:
=> 0x00007ffff7714bb0 <+0>:     mov    %fs:0x18,%eax
    0x00007ffff7714bb8 <+8>:     test   %eax,%eax
    0x00007ffff7714bba <+10>:    jne    0x7ffff7714bd0 <write+32>
    0x00007ffff7714bbc <+12>:    mov    $0x1,%eax
    0x00007ffff7714bc1 <+17>:    syscall
    0x00007ffff7714bc3 <+19>:    cmp    $0xfffffffffffff000,%rax
    0x00007ffff7714bc9 <+25>:    ja     0x7ffff7714c20 <write+112>
    0x00007ffff7714bcb <+27>:    ret
```

That's how you go from a `@safe` function main() down to a 
`syscall` instruction (then the rest is happening in the Linux 
kernel). Somewhere on this way a `@trusted` attribute needs to be 
used, which means *"please @trust me, these particular 
potentially unsafe things are used correctly here and won't cause 
troubles"*: 
https://github.com/dlang/phobos/blob/v2.101.0/std/stdio.d#L3187

As the end users, we expect that Phobos interacts with a 
dangerous system library (libc) in a correct way. Phobos itself 
annotates [trustedFPUTC/trustedFPUTWC 
functions](https://github.com/dlang/phobos/blob/v2.101.0/std/stdio.d#L354-L362) imported from glibc as `@trusted` and expects that they are interacting with the OS kernel correctly without causing troubles.

It's impossible to do a syscall by using just `@safe` code and 
nothing else.