On Sun, Apr 11, 2021 at 03:07:29PM -0400, Len Brown wrote:
> If it is the program, how does it know that the library wants to use
> what instructions?
>
> If it is the library, then you have just changed XCR0 at run-time and
> you expose breakage of the thread library that has computed XSAVE size.
So, when old programs which cannot possibly know about the arch_prctl()
extension we're proposing here, link against that library, then that
library should not be allowed to go use "fat" states.
Unless the library can "tell" the process which links to it, that it
has dynamically enlarged the save state. If it can and the process can
handle that, then all is fine, save state gets enlarged dynamically and
it all continues merrily.
Also, in order for the library to use fat states, it needs to ask the
kernel for such support - not CPUID - because the kernel is doing the
state handling for everybody and doing all the CR4.OSXSAVE setup etc.
Which also means that the kernel can help here by telling the library:
- No, you cannot use fat states with this process because it hasn't
called arch_prctl() so it cannot handle them properly.
- Yes, this process allowes me to handle fat states for it so you can
use those states and thus those instructions when doing operations for
it.
So the kernel becomes the arbiter in all this - as it should be - and
then all should work fine.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
