Don't clear FPU registers when using FPU_KERN_NOCTX

[jtl]

Summary

When using FPU_KERN_NOCTX, we do not have state from which to restore the registers. We also don't expect to ever save the registers. No code should assume they are in a pristine state. Therefore, it seems like we should not need to clear them.

Now that we are using FPU_KERN_NOCTX in more of the crypto code, it would be nice to avoid unnecessary cycles on register restoration, if possible.

[kib]

I do not have principled objections against this.

More as a curiosity than as a request for an action item from you, did you considered how this change would interact with miscellaneous data leaks from extended registers? Now we potentially keep the keying material in the arch registers, instead of some copies in the buffers or buses, so it might provide more direct routes to guess the values.

[jhb]

In D41865#954485, @kib wrote:

I do not have principled objections against this.

More as a curiosity than as a request for an action item from you, did you considered how this change would interact with miscellaneous data leaks from extended registers? Now we potentially keep the keying material in the arch registers, instead of some copies in the buffers or buses, so it might provide more direct routes to guess the values.

I have thought about this and before the NOCTX changes, we were definitely leaking material between operations on the same session. This does potentially leak across sessions which is wider exposure.

However, the main thing I was worrying about here is that we use whatever the current register values are, and those could be from a user thread. Thus, the one attack I was worrying about is a user thread that keeps setting the SSE/AVX registers to specific values (which it can do) and then triggers an in-kernel crypto operation and if something about the pre-existing register values permitted a side channel back to userland. What we could do to mitigate that case perhaps is make the fpurestore conditional and only do it in the case that we do an fpu_save above, so for the very first operation in a "batch" you do an XRSTOR, but not for back to back operations within a kthread.

[jhb]

sys/amd64/amd64/fpu.c

1145

This is where we might consider moving fpurestore() to avoid leaking exposing user register values to in-kernel consumers.

[kib]

sys/amd64/amd64/fpu.c

1145

May be. But then, it might be prudent to e.g. call mds_handler as well, at least.