copy_uabi_to_xstate(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… copy_uabi_to_xstate(9) β€” a Kernel API Manual moment

okay bestie, sit down, because we're about to talk about translating a UABI format buffer into the kernel's internal, hardware-dependent xstate format. it's giving "glow-up but for structs." ✨


🌸 NAME

copy_uabi_to_xstate β€” literally copy a UABI format buffer into the kernel's xstate 🫢


πŸŽ€ SYNOPSIS

int copy_uabi_to_xstate (struct fpstate *fpstate , const void *kbuf ,
const void __user *ubuf , u32 *pkru );

✨ ARGUMENTS

  • fpstate β€” the fpstate buffer you're copying to. the destination. the main character πŸ’–
  • kbuf β€” the UABI format buffer, but only if it's coming from the kernel πŸ‘€
  • ubuf β€” the UABI format buffer, but only if it's coming from userspace 🌸
  • pkru β€” where you write the PKRU value to. that's it, that's the whole job πŸŽ€

πŸ¦‹ DESCRIPTION

so what this bad boy does is convert from the UABI format into the kernel's internal, hardware-dependent format. lowkey iconic of it. πŸ’…

and here's the tea: this function ultimately has three different callers with distinct PKRU behavior. not two. not four. three. periodt. πŸ”₯

  1. when it's called from sigreturn, the PKRU register gets restored from fpstate via an XRSTOR. so correctly copying the UABI format buffer into fpstate is genuinely enough to cover this case β€” but the caller will also pass a pointer to the thread_struct's pkru field in pkru, and updating it is harmless. no cap, it's fine 🫢
  2. when it's called from ptrace, the PKRU register gets restored from the thread_struct's pkru field, and a pointer to that is passed in pkru. the kernel restores it manually, so that XRSTOR behavior β€” the one where the PKRU register gets reset to the hardware init value (0) if the corresponding xfeatures bit isn't set β€” gets emulated right here. yes, we're doing the emulation ourselves, we're built different 😭
  3. when it's called from KVM, the PKRU register gets restored from the vcpu's pkru field, and a pointer to that is passed in pkru. here's the thing though: KVM hasn't used XRSTOR, and it hasn't had that PKRU-resetting behavior described above. so to preserve that KVM behavior, it passes NULL for pkru if the xfeatures bit is not set. respect the legacy, bestie πŸ™ˆ
ngl, the whole point of this page is that pkru can mean three slightly different things depending on who's calling. know your caller. πŸ’€

🌈 SEE ALSO

go read those too, iykyk πŸ“š


and that's the whole page, bestie! πŸŽ€ this little gem lives in ./arch/x86/kernel/fpu and it's dated October 2026, all wrapped up in the Kernel API Manual. mwah, slay, go convert some buffers responsibly πŸ’–βœ¨πŸ‘‘

πŸ“¦ where this page comes from