grayresearch
commented
6 months ago I infer this Issue proposes the CX API cx_open() sometimes (following happenings on this thread) provides a selector for a CX state context that is NOT in the initial state. This must not ever happen because it violates the CX contract.
A CX is an immutable interface behavior contract for the CX's set of custom instructions (and soon, some custom CSRs too). This contract says, starting from an initial state and applying this set of custom instructions in this order, you get to this state and will observe such and such behavior and (sometimes even) values.
When a thread in a process opens a CX it must be in the initial state so that software that is written to this contract sees this contract.
Under composition there is no guarantee that when the OS sees cx_open() ... cx_close() ... cx_open() on a thread, the second open is another from the first library. It may be a different library that will exhibit undefined behavior if the CX contract is not honored.
There will be diverse use cases for CX API but in general CX libraries composed in a process or on a thread are separately authored and have a very weak notion of mutual trust.
One way to make work what you are trying to do here, within one CX library, is to cx_open() a CX state context once, and when it is idle, keep it in a data structure, don't cx_close() it, and next time this CX library needs a CX state context (and since it knows it may get a non-initial one) it can recycle the one it the library's own private data structure. Here the first CX library is not surprised it is starting with a recycled state context, and it doesn't break the second CX library that happens to also use this CX.
When an application opens/closes the same context several times, it may be advantagious to reuse the same state context. In this case, the cx_open() places the context into the initial state, which may incur some time delays.
instead, it might be desirable to allocate a new state context that is uninitialized. this would be a security hazard if the OS was allocating a context that had been previously used by a different process. however, if it is the same process, there is no such concern.
this would mimic the way malloc() recycles memory to the same process; when the OS provides the virtual pages initially, they are always cleaned, but when recycled they can be dirty.