NetBSD Problem Report #59114

From www@netbsd.org  Fri Feb 28 15:38:31 2025
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits)
	 client-signature RSA-PSS (2048 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 020391A923A
	for <gnats-bugs@gnats.NetBSD.org>; Fri, 28 Feb 2025 15:38:31 +0000 (UTC)
Message-Id: <20250228153829.8D1891A923D@mollari.NetBSD.org>
Date: Fri, 28 Feb 2025 15:38:29 +0000 (UTC)
From: campbell+netbsd@mumble.net
Reply-To: campbell+netbsd@mumble.net
To: gnats-bugs@NetBSD.org
Subject: hppa: eager fpu switching for qemu and/or spectre mitigation
X-Send-Pr-Version: www-1.0

>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)

Home	PR Database Search