4 ms·
I don't think 70% of bugs are memory safety issues. In my experience it's closer to 5%.
by mgaunard 10mo ago
I don't think 70% of bugs are memory safety issues.
In my experience it's closer to 5%.
- nibman 10mo ago[dead]
- redeeman 10mo agoprobably quite a bit less than 5%, however, they tend to be quite serious when they happen
- mgaunard 10mo agoOnly serious if you care about protecting from malicious actors running code on the same host.
- redeeman 10mo agoyou dont? I would imagine people that runs for example a browser would have quite an interest in that
- mgaunard 10mo agoBrowsers are sandboxed, and working on the web browsers themselves is a very small niche, as is working on kernels. Software increasingly runs either on dedicated infrastructure or virtual ones; in those cases there isn't really a case where you need to worry about software running on the same host trying to access the data. Sure, it's useful to have some restrictions in place to track what needs access to what resource, but in practice they can always be circumvented for debugging or convenience of development.
- yencabulator 10mo agoBrowsers are sandboxed by the kernel, and we're talking about bugs in the kernel here...
- mgaunard 10mo agoEven if modern browsers lean more on kernel features, initially the sandboxing in browsers is implemented through a managed runtime.
- cogman10 10mo agoI believe this is where that fact comes from [1] Basically, 70% of high severity bugs are memory safety. [1] https://www.chromium.org/Home/chromium-security/memory-safety/ https://www.chromium.org/Home/chromium-security/memory-safet...
- tester756 10mo agoThat's the figure that Microsoft and Google found in their code bases.
- IshKebab 10mo ago70% of security vulnerabilities are due to memory safety. Not all bugs.
- stonemetal12 10mo agoUsing the data provided, memory safety issues (use-after-free, memory-leak, buffer-overflow, null-deref) account for 67% of their bugs. If we include refcount It is just over 80%.