I think this is a larger issue, which we're facing with virtualization.

In the best case, the set mode methods are checked statically: if an implementation can provide them it does, and if it doesn't it doesn't. That way if a client needs a certain mode, you can't connect it to an implementation that doesn't implement it.

The issue with this is virtualizers. If you say that a virtualizer implements only the traits its underlying resource implements, you end up with lots of different virtualizers: this one supports AES128CBC, that one supports AES128CBC+AES128ECB, etc.

I see 4 ways forward:

1. Forget the "trait per mode" approach, and go fully dynamic, using an enum. If you request a mode not supported, it returns and error.
2. Keep the "trait per mode" approach, for static binding in the kernel, but introduce error return values because we want a single virtualizer implementation (the current approach).
3. Have a variety of virtualizer implementations, supporting different cipher suites.
4. Refactor how these traits work such that the virtualizer is parameterized by a type which implements the set_mode methods, such that system calls can get runtime errors but any given set_mode doesn't. This is pared down version of 3: we have a single virtualizer implementation, but multiple implementations of what cipher suites are supported.

There are certainly others. But what I want to avoid is pushing us towards run-time checks (motivated by userspace) that be checked statically for in-kernel use.