Tighten context management in ALT implementations

[gilles-peskine-arm]

Context and rationale

Alternative implementations of whole modules may define their own context type. We do not explicitly specify whether an alternative implementation is allowed to maintain a pointer to contexts while no function using this context is active, or to remember the address of a context inside the context itself. As a consequence, it is not permitted for applications to move a context structure in memory, which can happen if the structure lives in managed memory.

Our own implementation of mbedtls_aes_context takes advantage of this implicit permission to maintain a pointer to the context: ctx->rk points inside ctx->buf (this is done for the sole sake of the MBEDTLS_PADLOCK_C implementation, because it requires a particular alignment in memory). This is a problem in practice: #2147.

Proposal

Document that in Mbed TLS 3, alternative implementations must allow moving a context structure in memory while no function operating on this context is active.

The reason this needs to be done in 3.0 is that it can break some existing applications.

This is a sort of extension of #4371.

Work items for 3.0

• Write the requisite documentation. It's basically one paragraph, but I don't know where it would go.

Work items for 3.x

• Fix the built-in AES context (reported as Make mbedtls_aes_context be shallow-copyable #2147). It's easy: change ctx->rk field to ctx->buf + ctx->rk_offset.
• Add tests that move a context around, to validate that the contract is not broken. Filed as Test that operation contexts are movable #4599.