Generalized address-space isolation

> This sounds like the kind of thing that might be a good candidate for a future Rust successor language with even more memory safety language support baked into the language. In this case annotating bits of data as sensitive and when it has to be mapped.

Rust should already be powerful enough to accomplish most of this.

You can use a special allocator for sensitive data, ensuring sensitive data always lives in the correct subset of the memory. And the type system can enforce that the sensitive data is mapped whenever it is needed. Just define an operation that maps the sensitive memory and returns a zero sized struct SENSITIVE_MAPPED that proves that the sensitive memory is mapped. Now all operations on sensitive memory require that struct. Thus you cannot do operations without mapping the sensitive memory. The operation that unmaps the sensitive memory will consume the SENSITIVE_MAPPED struct.

At first, this might look like a performance impact, but as this is a zero sized struct that is not used at all in the operations (it just has to be there), there is no need for the compiler to emit any code regarding that struct. It is just a marker.

What will be hard is to enforce that the sensitive memory is not mapped when it is not needed. Probably you could use another token that proves that is returned by the unmap operation (and consumed by the map operation) that is required when you do things that can potentially leak data.

While this might not come with some runtime penalty, it requires of course much implementation effort to do all this. Probably most of the effort will be to identify everything that is sensitive.