Scott Johnson wrote:

It seems the use model is to enable older environment-swapping software to
run on newer hardware without opening a security hole via new state. Only
if the software is aware of the state will it enable that state via
*stateen.

For custom state, you can always make custom *stateen-like CSRs to enable
it. You're going to need custom software to swap that state anyway.

Yes, that's exactly what we were thinking.

But there's also the use model of the M-mode software that doesn't do any
environment swapping and just wants to enable all state for the S-mode. It
would be nice if that didn't have to be aware of custom state.

So, I join Bill in his question. It seems a good idea to reserve some bits
for custom state for that latter use model.

This seems like a sensible request to me, except I would accomplish the
same effect by adding a single "write-only" bit to mstateen0. The bit
always reads as zero, and writing zero to it does nothing; but writing
a one causes all custom state to be enabled for lower privilege levels.
As you suggested, there will presumably be custom CSRs containing
one or more bits that control access to the custom state, akin to
the mstateen CSRs for standardized state. Machine-level software may
consult and modify those custom-state-controlling bits directly if it
has sufficient knowledge, but won't have to.

- John Hauser