В ядре Linux устранена следующая уязвимость:
x86/fpu: очищать XSTATE_BV[i] в гостевом состоянии XSAVE всякий раз, когда XFD[i]=1
При загрузке состояния гостевого XSAVE через KVM_SET_XSAVE и при обновлении XFD в
ответ на гостевой WRMSR, очистите отключенные функции XFD в сохраненных (или в
быть восстановлено) XSTATE_BV, чтобы гарантировать, что KVM не пытается загрузить состояние для
функции, которые отключены через XFD гостя. Потому что ядро
выполняет XRSTOR с XFD гостя, сохраняя XSTATE_BV[i]=1 с XFD[i]=1
приведет к тому, что XRSTOR перейдет в #NM и вызовет панику в ядре. Например. если fpu_update_guest_xfd() устанавливает XFD без очистки XSTATE_BV:
------------[вырезать здесь]------------
ВНИМАНИЕ: Arch/x86/kernel/traps.c:1524 по адресу exc_device_not_available+0x101/0x110, CPU#29: amx_test/848
Связанные модули: kvm_intel kvm irqbypass
ЦП: 29 UID: 1000 PID: 848 Связь: amx_test Не испорчено 6.19.0-rc2-ffa07f7fd437-x86_amx_nm_xfd_non_init-vm #171 НЕТ
Название оборудования: QEMU Standard PC (Q35+ICH9, 2009 г.), BIOS 0.0.0 от 06.02.2015 г.
RIP: 0010:exc_device_not_available+0x101/0x110
Отслеживание вызова:
<ЗАДАЧА>
asm_exc_device_not_available+0x1a/0x20
RIP: 0010:restore_fpregs_from_fpstate+0x36/0x90
switch_fpu_return+0x4a/0xb0
kvm_arch_vcpu_ioctl_run+0x1245/0x1e40 [kvm]
kvm_vcpu_ioctl+0x2c3/0x8f0 [квм]
__x64_sys_ioctl+0x8f/0xd0
do_syscall_64+0x62/0x940
запись_SYSCALL_64_after_hwframe+0x4b/0x53
</TASK>
---[ конечная трассировка 0000000000000000 ]---
Это может произойти, если гость выполняет WRMSR(MSR_IA32_XFD), чтобы установить XFD[18] = 1,
и IRQ хоста запускает kernel_fpu_begin() до того, как обработчик vmexit
вызов fpu_update_guest_xfd().
и если пользовательское пространство заполняет XSTATE_BV[i]=1 через KVM_SET_XSAVE:
------------[вырезать здесь]------------
ВНИМАНИЕ: Arch/x86/kernel/traps.c:1524 по адресу exc_device_not_available+0x101/0x110, CPU#14: amx_test/867
Связанные модули: kvm_intel kvm irqbypass
ЦП: 14 UID: 1000 PID: 867 Связь: amx_test Не испорчено 6.19.0-rc2-2dace9faccd6-x86_amx_nm_xfd_non_init-vm #168 НЕТ
Название оборудования: QEMU Standard PC (Q35+ICH9, 2009 г.), BIOS 0.0.0 от 06.02.2015 г. RIP: 0010:exc_device_not_available+0x101/0x110
Отслеживание вызова:
<ЗАДАЧА>
asm_exc_device_not_available+0x1a/0x20
RIP: 0010:restore_fpregs_from_fpstate+0x36/0x90
fpu_swap_kvm_fpstate+0x6b/0x120
kvm_load_guest_fpu+0x30/0x80 [квм]
kvm_arch_vcpu_ioctl_run+0x85/0x1e40 [kvm]
kvm_vcpu_ioctl+0x2c3/0x8f0 [квм]
__x64_sys_ioctl+0x8f/0xd0
do_syscall_64+0x62/0x940
запись_SYSCALL_64_after_hwframe+0x4b/0x53
</TASK>
---[ конечная трассировка 0000000000000000 ]---
Новое поведение соответствует архитектуре AMX. Согласно SDM Intel,
XSAVE сохраняет XSTATE_BV как «0» для компонентов, отключенных через XFD.
(а некомпактный XSAVE сохраняет первоначальную конфигурацию состояния
компонент):
Если XSAVE, XSAVEC, XSAVEOPT или XSAVES сохраняет компонент состояния i,
инструкция не генерирует #NM, когда XCR0[i] = IA32_XFD[i] = 1;
вместо этого он работает так, как если бы XINUSE[i] = 0 (и компонент состояния был
в исходном состоянии): он сохраняет бит i поля XSTATE_BV файла XSAVE.
заголовок как 0; кроме того, XSAVE сохраняет первоначальную конфигурацию
компонент состояния (другие инструкции не сохраняют компонент состояния i).
Альтернативно, KVM всегда может выполнить XRSTOR с XFD=0, например. используя
постоянный XFD, основанный на наборе включенных функций при XSAVE для
структура fpu_guest. Однако наличие XSTATE_BV[i]=1 для отключенного XFD
функции могут произойти только в приведенном выше случае прерывания или в аналогичном случае.
сценарии, включающие вытеснение в вытесняемых ядрах, поскольку
Вызов fpu_swap_kvm_fpstate() метода save_fpregs_to_fpstate() сохраняет
исходящее состояние FPU с текущим XFD; и это (во всем, кроме
первый WRMSR в XFD) гостевой XFD. Следовательно, XFD может только рассинхронизироваться с XSTATE_BV в приведенном выше примере.
случае прерывания или в аналогичных сценариях, включающих вытеснение
вытесняемые ядра, и это мы можем считать (де-факто) частью KVM
ABI, который KVM_GET_XSAVE возвращает XSTATE_BV[i]=0 для функций с отключенной XFD.
[Переместить Клеа
---усечено---
Показать оригинальное описание (EN)
In the Linux kernel, the following vulnerability has been resolved: x86/fpu: Clear XSTATE_BV[i] in guest XSAVE state whenever XFD[i]=1 When loading guest XSAVE state via KVM_SET_XSAVE, and when updating XFD in response to a guest WRMSR, clear XFD-disabled features in the saved (or to be restored) XSTATE_BV to ensure KVM doesn't attempt to load state for features that are disabled via the guest's XFD. Because the kernel executes XRSTOR with the guest's XFD, saving XSTATE_BV[i]=1 with XFD[i]=1 will cause XRSTOR to #NM and panic the kernel. E.g. if fpu_update_guest_xfd() sets XFD without clearing XSTATE_BV: ------------[ cut here ]------------ WARNING: arch/x86/kernel/traps.c:1524 at exc_device_not_available+0x101/0x110, CPU#29: amx_test/848 Modules linked in: kvm_intel kvm irqbypass CPU: 29 UID: 1000 PID: 848 Comm: amx_test Not tainted 6.19.0-rc2-ffa07f7fd437-x86_amx_nm_xfd_non_init-vm #171 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:exc_device_not_available+0x101/0x110 Call Trace: <TASK> asm_exc_device_not_available+0x1a/0x20 RIP: 0010:restore_fpregs_from_fpstate+0x36/0x90 switch_fpu_return+0x4a/0xb0 kvm_arch_vcpu_ioctl_run+0x1245/0x1e40 [kvm] kvm_vcpu_ioctl+0x2c3/0x8f0 [kvm] __x64_sys_ioctl+0x8f/0xd0 do_syscall_64+0x62/0x940 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK> ---[ end trace 0000000000000000 ]--- This can happen if the guest executes WRMSR(MSR_IA32_XFD) to set XFD[18] = 1, and a host IRQ triggers kernel_fpu_begin() prior to the vmexit handler's call to fpu_update_guest_xfd(). and if userspace stuffs XSTATE_BV[i]=1 via KVM_SET_XSAVE: ------------[ cut here ]------------ WARNING: arch/x86/kernel/traps.c:1524 at exc_device_not_available+0x101/0x110, CPU#14: amx_test/867 Modules linked in: kvm_intel kvm irqbypass CPU: 14 UID: 1000 PID: 867 Comm: amx_test Not tainted 6.19.0-rc2-2dace9faccd6-x86_amx_nm_xfd_non_init-vm #168 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:exc_device_not_available+0x101/0x110 Call Trace: <TASK> asm_exc_device_not_available+0x1a/0x20 RIP: 0010:restore_fpregs_from_fpstate+0x36/0x90 fpu_swap_kvm_fpstate+0x6b/0x120 kvm_load_guest_fpu+0x30/0x80 [kvm] kvm_arch_vcpu_ioctl_run+0x85/0x1e40 [kvm] kvm_vcpu_ioctl+0x2c3/0x8f0 [kvm] __x64_sys_ioctl+0x8f/0xd0 do_syscall_64+0x62/0x940 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK> ---[ end trace 0000000000000000 ]--- The new behavior is consistent with the AMX architecture. Per Intel's SDM, XSAVE saves XSTATE_BV as '0' for components that are disabled via XFD (and non-compacted XSAVE saves the initial configuration of the state component): If XSAVE, XSAVEC, XSAVEOPT, or XSAVES is saving the state component i, the instruction does not generate #NM when XCR0[i] = IA32_XFD[i] = 1; instead, it operates as if XINUSE[i] = 0 (and the state component was in its initial state): it saves bit i of XSTATE_BV field of the XSAVE header as 0; in addition, XSAVE saves the initial configuration of the state component (the other instructions do not save state component i). Alternatively, KVM could always do XRSTOR with XFD=0, e.g. by using a constant XFD based on the set of enabled features when XSAVEing for a struct fpu_guest. However, having XSTATE_BV[i]=1 for XFD-disabled features can only happen in the above interrupt case, or in similar scenarios involving preemption on preemptible kernels, because fpu_swap_kvm_fpstate()'s call to save_fpregs_to_fpstate() saves the outgoing FPU state with the current XFD; and that is (on all but the first WRMSR to XFD) the guest XFD. Therefore, XFD can only go out of sync with XSTATE_BV in the above interrupt case, or in similar scenarios involving preemption on preemptible kernels, and it we can consider it (de facto) part of KVM ABI that KVM_GET_XSAVE returns XSTATE_BV[i]=0 for XFD-disabled features. [Move clea ---truncated---