RFC ideas

[tarcieri]

This is a tracking ticket for potential ideas for Rust security improvements to the core language and standard library to be submitted via the RFC process at https://github.com/rust-lang/rfcs

The idea here is list some potential RFC items and then coordinate who (if anybody) wants to work on them. Once we've figured that out we can go from there.

Feel free to edit the list below or request it be edited in the comments:

Secure Zeroing Intrinsic

Potential Authors: @tarcieri

Stabilize core::intrinsics::volatile_set_memory, at least for the case where val (i.e. byte to write) is 0, for the purposes of securely zeroizing memory.

This avoids the need to rely on OS-specific APIs/FFI or "weird tricks" to ensure secure memory zeroing operations are not optimized away.

Annotations for Overflow Behavior

Potential Authors: ???

Stabilize an annotation API similar to what the overflower crate provides on nightly Rust, with annotations like:

• #[overflow(panic)]
• #[overflow(wrap)]
• #[overflow(saturate)]

Byte-level conversions between types

Potential Authors: @joshlf

Add traits and auto impls to the language to express the idea that, given any valid instance of T, the bytes of that instance also constitute a valid instance of U. Particularly useful for zero-copy parsing/serialization, SIMD, and unlocking Atomic<T>.

An early draft that will need to be completely overhauled is here. Code which implements a subset of this concept is here.

Fixed-capacity Vec view

Potential Authors: @Shnatsel

This is used to address a use case for appending contents of a vector to itself. This is a common pattern in decompressors of all kinds (gzip, audio, images), but people doing it in practice tend to end up with implementations that are slow, unsafe, or both. See this pre-RFC for rather in-depth info.

[briansmith]

I think it would be better to just submit each of these as a separate issue instead of having a meta-issue with many sub-issues. That is, it would be easier to deal with this kind of thing if there were a 1:1 correspondence between issues and proposals.

[tarcieri]

@briansmith this was just a quick ideas list for people who might want to work on the same RFCs to coordinate on collaboration. In the description I had suggested:

The idea here is list some potential RFC items and then coordinate who (if anybody) wants to work on them. Once we've figured that out we can go from there.

The next issues I feel we should open after this are the RFCs themselves (or Discourse pre-RFC threads).

[burdges]

Is there a way to selectively impose security lint on dependencies? This came up in the unicode RFC, but you guys would care much more about it for restrictions on unsafe.

How would this work with unsafe? It'd mean that code would stop compiling when a dependency not authorized to use unsafe started using it. To actually do this well, you'd need to patch the dependency for each unsafe usage, which makes cargo unhappy, but another solution might appear.

[Shnatsel]

For the record, this came out of safety-dance: https://github.com/rust-lang/rust/pull/64069

I've also opened an RFC for another missing safe abstraction: https://github.com/rust-lang/rfcs/pull/2714

I also need to turn this into an RFC for Cargo: https://github.com/Shnatsel/rust-audit

[Shnatsel]

Another one came out of a discussion I started on clippy lints: https://github.com/rust-lang/rfcs/pull/2756