Should more .NET Library code be re-written w/o Unsafe v1 and v2 given CVE increases?

[toupswork]

• Given that we are seeing a potential exponential growth in CVEs reported & fixed from AI analyzers-- e.g., from July to October, there was a 622% jump (source)--should more CoreLIb and other library code be re-written without Unsafe V1 & V2?

• We see that Egor Bo is rewriting the Brotoli algorithm in memory safe C# following the Brotoli security flaw (opps, looks like he shut down his work on that for some reason)

• Not the removal of ALL unsafe code, but areas that are highly susceptible to exploitation

• Yes, there are things where this may be impracticable, e.g., SIMD requiring alignment of 16, 32, or 64 when the GC is pointer aligned (x64) (Edit: yes there are safe alternatives for Store(), but then you forfeit an atomic opcode, thus performance penalty)

• Yes, the JIT loses optimization opportunities due to lack of knowledge it needs to prove optimization-requisite invariants, plus its inability to perform advanced analysis while it's running without freezing the app

• But then does that make Andy Ayers' proposal of providing inter-procedural analysis data alongside the IL to assist with that more urgent? (See his post)

Edit: I would argue this is more important than a "nice addition, but not a make-or-break". Take guarded optimizations just as an example out of many. There are many cases where the guard is not needed but the RyuJIT can't know that for certain without IPA. Yes, the IPA would need to be slimmed down to not recreate the same runtime pausing issue it's trying to prevent, as well as large assemblies. But the JIT has a hard time optimizing IL that can come from multiple languages that all have different invariants with many invariants being non-runtime enforced, bypassed with IL injection/weaving, or reflection, which is why metadata can't always be trusted-- e.g C# new closed classes or private protected ctors before that. If the IPA can be generated based on the source language's invariants, then that opens up all kinds of guarantees that lead to better devirtualization, alias detection, bound checks, and escape analysis. And right now, the JIT heavily depends on inlining, which if done incorrectly, can create iCache issues.

[EgorBo]

• Given that we are seeing a potential exponential growth in CVEs reported & fixed from AI analyzers-- e.g., from July to October, there was a 622% jump (source)--should more CoreLIb and other library code be re-written without Unsafe V1 & V2?

That is the goal. Currently, it's blocked by #131451 because we want to use the tools we'll offer to users for the migration (i.e., dogfood them). Obviously, AI can already do it today, but the migration workflow is intended to significantly reduce token consumption.

• We see that Egor Bo is rewriting the Brotoli algorithm in memory safe C# following the Brotoli security flaw (opps, looks like he shut down his work on that for some reason)

I had that idea in mind long before any CVE was found there. I was interested in the performance of managed, safe C# versus unsafe C. I was pretty satisfied with the numbers and closed the PR. We might revisit the idea, but I can't promise anything, while I made it safe I still had to use ArrayPool in a quite unsafe way and it needs an advanced ownership/lifetime features in C# first.

• Not the removal of ALL unsafe code, but areas that are highly susceptible to exploitation

It is an ongoing effort that can be tracked using this query: https://github.com/dotnet/runtime/pulls?q=is%3Apr++label%3Areduce-unsafe. Any PR that helps by removing unsafe code and demonstrating zero performance overhead is greatly appreciated.

• Yes, there are things where this may be impracticable, e.g., SIMD requiring alignment of 16, 32, or 64 when the GC is pointer aligned (x64)

That can be made safe: it's fine if the GC changes the alignment (a rare event), as it shouldn't cause correctness issues.

• Yes, the JIT loses optimization opportunities due to lack of knowledge it needs to prove optimization-requisite invariants, plus its inability to perform advanced analysis while it's running without freezing the app
• But then does that make Andy Ayers' proposal of providing inter-procedural analysis data alongside the IL to assist with that more urgent? (See his post)

Interprocedural analysis is important, but so far, most uses of unsafe code can be replaced with safe code without it.

[toupswork]

BAM! You nailed every bullet point. Thanks, Egor!