x86/fpu: Document signal frame layout and portability

The x86 signal frame is designed to be self-describing, with the
'xstate_size' field in the software-reserved bytes indicating the actual
size of the context. This design is required for portability, allowing a
signal frame created on a system with a specific set of xstate features
to be restored on a machine with a different (larger) set of features.

Signed-off-by: Andrei Vagin <avagin@google.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Alexander Mikhalitsyn <alexander@mihalicyn.com>
Link: https://patch.msgid.link/20260925162454.1403405-2-avagin@google.com
This commit is contained in:
Andrei Vagin 2026-09-25 16:24:47 +00:00 committed by Borislav Petkov (AMD)
parent c0a44d1745
commit 3d69596c68
2 changed files with 69 additions and 0 deletions

View File

@ -172,3 +172,57 @@ are extended to control the guest permission:
Note that some VMMs may have already established a set of supported state
components. These options are not presumed to support any particular VMM.
Signal Frame Layout and Portability
-----------------------------------
The signal frame is designed to be self-describing and portable. This is
especially important for checkpoint/restore tools like CRIU, which may restore
a process on a different host than where it was checkpointed. A signal frame
created on a machine with fewer CPU features can be successfully restored on a
machine with more CPU features, but not vice-versa.
Signal Frame Software Reserved Bytes
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
On CPUs supporting XSAVE, bytes 464..511 in the 512-byte FXSAVE/FXRSTOR frame
are reserved for software use and contain ``struct _fpx_sw_bytes`` (defined in
``<uapi/asm/sigcontext.h>``)::
struct _fpx_sw_bytes {
__u32 magic1;
__u32 extended_size;
__u64 xfeatures;
__u32 xstate_size;
__u32 padding[7];
};
- ``magic1``: Set to ``FP_XSTATE_MAGIC1`` (``0x46505853U``) if an extended
xstate context is present; 0 for a legacy frame.
- ``extended_size``: The total size allocated on the stack for the frame,
measured from the ``fpstate`` pointer. In 32-bit signal frames, this also
includes the 112-byte legacy FPU state prefix of ``struct _fpstate_32``.
- ``xfeatures``: The mask of xstate features saved in the frame.
- ``xstate_size``: The actual size of the xstate context for the enabled
features (including the 512-byte FXSAVE area and the 64-byte XSAVE header).
The kernel uses ``xstate_size`` in conjunction with the pointer to the xstate
context to locate the ``FP_XSTATE_MAGIC2`` (``0x46505845U``) marker right after
the xstate context (at ``xstate_context + xstate_size``). In 64-bit signal frames,
the ``fpstate`` pointer points directly to the xstate context. In 32-bit signal
frames (including 32-bit compat tasks on 64-bit kernels), the ``fpstate``
pointer points to ``struct _fpstate_32``, which contains the 112-byte legacy
FPU state followed by the 512-byte FXSR state (and any extended xstate). Since
there is no standalone UAPI structure defined for just the 112-byte legacy
state, the xstate context starts at ``fpstate + 112`` (and ``extended_size``
spans the entire allocation from ``fpstate``).
Portability Constraints
^^^^^^^^^^^^^^^^^^^^^^^
Signal frame portability is constrained by the architectural XSAVE layout.
Restoration is supported only if the destination host supports all features
present in the frame and uses matching component offsets and sizes for them.
While layout compatibility is generally maintained across CPUs from the same
vendor, differences can occur across vendors or if the XSAVE space of a
deprecated feature (e.g. MPX) is repurposed for a newer feature (e.g. APX).

View File

@ -34,6 +34,21 @@
* fpstate+extended_size-FP_XSTATE_MAGIC2_SIZE address) is set to
* FP_XSTATE_MAGIC2 so that you can sanity check your size calculations.)
*
* The xstate_size field indicates the actual size of the xstate context
* (including the 512-byte FXSAVE area and the 64-byte XSAVE header struct
* _header). This size is used in conjunction with the pointer to the xstate
* context to locate FP_XSTATE_MAGIC2.
*
* In 64-bit signal frames, the fpstate pointer points directly to the xstate
* context. In 32-bit signal frames (including 32-bit compat tasks on 64-bit
* kernels), the fpstate pointer points to struct _fpstate_32, which contains
* the 112-byte legacy FPU state followed by the 512-byte FXSR state (and any
* extended xstate), so the xstate context starts at fpstate + 112.
*
* This makes the signal frame self-describing and portable across machines
* with different xstate features. See Documentation/arch/x86/xstate.rst
* for details on signal frame portability and its architectural constraints.
*
* This extended area typically grows with newer CPUs that have larger and
* larger XSAVE areas.
*/