port-hppa/59114: hppa: eager fpu switching for qemu and/or spectre mitigation

[campbell+netbsd%mumble.net@localhost]

>Number:         59114
>Category:       port-hppa
>Synopsis:       hppa: eager fpu switching for qemu and/or spectre mitigation
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-hppa-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Feb 28 15:40:01 +0000 2025
>Originator:     Taylor R Campbell
>Release:        current, 10, 9, ...
>Organization:
The NetHPPA Flotation
>Environment:
>Description:
Currently NetBSD/hppa uses lazy FPU switching: when a process first executes a floating-point instruction, it traps to the kernel and the kernel enables the FPU and loads state from memory into the FPU; when switching to another process it doesn't save the FPU state to memory until the other process tries to use the FPU.

This doesn't work in qemu (as of 8.x) because qemu doesn't trap on floating-point instructions even when the FPU is disabled by clearing the relevant bits of CR10 `Coprocessor Control Register' (CCR).

If any hppa hardware implements speculative execution, lazy FPU switching is also likely to have exploitable Spectre-class side channels -- the CPU may speculatively execute instructions past the trapping one before determining the trap, and the speculative execution may alter cache contents depending on secret register content in some architecturally observable way.
>How-To-Repeat:
run NetBSD/hppa under qemu and do tests with the floating-point registers, like /usr/tests/kernel/t_execregs
>Fix:
Ditch lazy FPU switching and implement eager FPU switching.

1. save FPU state on trap from userland, or from kernel threads with l->l_flag & LW_SYSTEM_FPU set (kthreads during kthread_fpu_enter/exit)
2. restore FPU state on return to userland, or to kernel threads with l->l_flag & LW_SYSTEM_FPU set
3. ditch all the lazy FPU switching logic in hppa_fpu_emulate (hppa_fpu_swap, hppa_fpu_swapout)