[OT] NSA guidance on software security

Siarhei Siamashka siarhei.siamashka at gmail.com
Fri Nov 11 19:51:33 UTC 2022


On Friday, 11 November 2022 at 18:24:46 UTC, Nick Treleaven wrote:
>>> Just declare main @safe.
>>
>> Have you missed my comment, which was talking about exactly 
>> that?
>
> You didn't mention main.

I apologise. I didn't think that you are unfamiliar with this 
particular language construct. Check 
https://dlang.org/spec/attribute.html and search the "affects all 
declarations until the end" substring to find the relevant part 
of documentation.

Basically you can put "@safe:" in the beginning of your program 
and all functions (the main function too) will be @safe by 
default.


>
>>> Memory unsafety is non deterministic. Overflow/underflow is, 
>>> so it's much less important.
>>
>> Neither is deterministic. Unless you have strictly 
>> deterministic input data.
>
> Whatever the input data, without memory safety you can't 
> trigger the bug through testing alone. It might never occur
> on your system, only on your client's.

There may be certain input data patterns, which are not properly 
stressed by your local testing setup. And only manifest 
themselves on a client's system. If that's not enough to convince 
you, there are also many CVEs that mention "integer overflow".

Moreover, paged virtual memory used in modern computers already 
provides some kind of rudimentary memory safety (with page 
granularity). Your client may get a "segmentation fault" error 
with a core dump or a crash dump file, which can be used by you 
to debug the issue. Debugging an arithmetic overflow bug may be a 
lot more tricky.

> That's why the NSA recognises memory safety bugs as 
> categorically worse
> than logic bugs or overflow/underflow.

Can you prove this claim by providing a citation?


More information about the Digitalmars-d mailing list