Generalized address-space isolation [LWN.net]

Generalized address-space isolation

Posted Mar 4, 2022 9:00 UTC (Fri) by taladar (subscriber, #68407)
Parent article: Generalized address-space isolation

> One reason for this approach should be reasonably clear: the kernel's address space is huge, and nobody could ever hope to properly determine the sensitivity of every data structure the kernel uses and mark it accordingly. Beyond that, somebody would have to find all of the places where the kernel must exit any restricted class to work with the sensitive data. Even if somebody did achieve all of that, there would be no hope of maintaining it going forward. This architecture thus embodies an acknowledgment that it will never be possible to properly mark all data and all places where sensitive data must be used, so it will always be necessary to make things work anyway.

While I agree that it would be a huge effort to properly mark everything in the kernel I feel the second half of this paragraph is too pessimistic. If there was a kernel codebase where this had already happened (or, say, a hypothetical rewrite where this was built in from the start) I think it would absolutely be possible to maintain this going forward, possibly with some tooling support.

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.

It sort of reminds me of the experiments in some languages for tainted data (Ruby comes to mind).

to post comments

Generalized address-space isolation

Posted Mar 4, 2022 10:18 UTC (Fri) by matthias (subscriber, #94967) [Link]

> 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.