diff mbox series

[2/2] cpu: virt: Downgrade message about virtualization disabled

Message ID 20250410201630.2996785-2-superm1@kernel.org
State Superseded
Headers show
Series [1/2] cpu/msr: Drop `VM_HSAVE_PA` from consistency checks | expand

Commit Message

Mario Limonciello April 10, 2025, 8:16 p.m. UTC
From: Mario Limonciello <mario.limonciello@amd.com>

Modern machines that ship with Microsoft Security Levels enabled
will lock down SVM.  This is by design, so decrease existing failure
to 'advice' instead.

Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
---
 src/cpu/virt/virt_svm.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

Comments

Ivan Hu April 11, 2025, 8:06 a.m. UTC | #1
Hi Mario,

We happened to discuss this test internally and might need some clarification from your team.

Currently, the fwts virt_svm test on AMD CPUs checks the EFER MSR (0xC0000080),
Secure Virtual Machine Enable (SVME) Bit. Bit 12, read/write. Enables the SVM extensions.
When this bit is zero, the SVM instructions cause #UD exceptions. EFER.SVME defaults to a reset
value of zero. The effect of turning off EFER.SVME while a guest is running is undefined; therefore,
the VMM should always prevent guests from writing EFER. SVM extensions can be disabled by
setting VM_CR.SVME_DISABLE. For more information, see descriptions of LOCK and
SMVE_DISABLE bits in Section 15.30.1 “VM_CR MSR (C001_0114h),” on page 583.

However, in practice, the behavior also depends on bit 3 (LOCK) and bit 4 (SVMDIS) of the VM_CR MSR (C001_0114h):
VM_CR MSR (C001_0114h)
LOCK—Bit 3. When this bit is set, writes to LOCK and SVMDIS are silently ignored. When this
bit is clear, VM_CR bits 3 and 4 can be written. Once set, LOCK can only be cleared using the
SVM_KEY MSR (See Section 15.31.) This bit is not affected by INIT or SKINIT.
SVMDIS—Bit 4. When this bit is set, writes to EFER treat the SVME bit as MBZ. When this bit is
clear, EFER.SVME can be written normally. This bit does not prevent CPUID from reporting that
SVM is available. Setting SVMDIS while EFER.SVME is 1 generates a #GP fault, regardless of
the current state of VM_CR.LOCK. This bit is not affected by SKINIT. It is cleared by INIT when
LOCK is cleared to 0; otherwise, it is not affected.

Given this, we would like to clarify:
Which MSR should be used for this test? And what is the expected MSR bit configuration that firmware (BIOS) should set to enable SVM correctly and pass the test?

Cheers,
Ivan

On 2025/4/11 04:16, Mario Limonciello wrote:
> From: Mario Limonciello <mario.limonciello@amd.com>
> 
> Modern machines that ship with Microsoft Security Levels enabled
> will lock down SVM.  This is by design, so decrease existing failure
> to 'advice' instead.
> 
> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
> ---
>   src/cpu/virt/virt_svm.c | 4 +---
>   1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/src/cpu/virt/virt_svm.c b/src/cpu/virt/virt_svm.c
> index d86f54f4..8cee9aaf 100644
> --- a/src/cpu/virt/virt_svm.c
> +++ b/src/cpu/virt/virt_svm.c
> @@ -77,9 +77,7 @@ void virt_check_svm(fwts_framework *fw)
>   			fwts_passed(fw, "Virtualization extensions supported and enabled by BIOS.");
>   			break;
>   		case 1:
> -			fwts_failed(fw, LOG_LEVEL_MEDIUM,
> -				"VirtDisabledByBIOS",
> -				"Virtualization extensions supported but disabled by BIOS.");
> +			fwts_advice(fw, "Virtualization extensions supported but disabled by BIOS.");
>   			break;
>   		default:
>   			fwts_log_error(fw, "Virtualization extensions check failed - cannot read msr.");
Ivan Hu April 15, 2025, 3:55 a.m. UTC | #2
Add Mario's email.

Hi Mario,
Please help us with clarification on the MSRs below.

Cheers,
Ivan

On 2025/4/11 16:06, ivanhu wrote:
> Hi Mario,
> 
> We happened to discuss this test internally and might need some clarification from your team.
> 
> Currently, the fwts virt_svm test on AMD CPUs checks the EFER MSR (0xC0000080),
> Secure Virtual Machine Enable (SVME) Bit. Bit 12, read/write. Enables the SVM extensions.
> When this bit is zero, the SVM instructions cause #UD exceptions. EFER.SVME defaults to a reset
> value of zero. The effect of turning off EFER.SVME while a guest is running is undefined; therefore,
> the VMM should always prevent guests from writing EFER. SVM extensions can be disabled by
> setting VM_CR.SVME_DISABLE. For more information, see descriptions of LOCK and
> SMVE_DISABLE bits in Section 15.30.1 “VM_CR MSR (C001_0114h),” on page 583.
> 
> However, in practice, the behavior also depends on bit 3 (LOCK) and bit 4 (SVMDIS) of the VM_CR MSR (C001_0114h):
> VM_CR MSR (C001_0114h)
> LOCK—Bit 3. When this bit is set, writes to LOCK and SVMDIS are silently ignored. When this
> bit is clear, VM_CR bits 3 and 4 can be written. Once set, LOCK can only be cleared using the
> SVM_KEY MSR (See Section 15.31.) This bit is not affected by INIT or SKINIT.
> SVMDIS—Bit 4. When this bit is set, writes to EFER treat the SVME bit as MBZ. When this bit is
> clear, EFER.SVME can be written normally. This bit does not prevent CPUID from reporting that
> SVM is available. Setting SVMDIS while EFER.SVME is 1 generates a #GP fault, regardless of
> the current state of VM_CR.LOCK. This bit is not affected by SKINIT. It is cleared by INIT when
> LOCK is cleared to 0; otherwise, it is not affected.
> 
> Given this, we would like to clarify:
> Which MSR should be used for this test? And what is the expected MSR bit configuration that firmware (BIOS) should set to enable SVM correctly and pass the test?
> 
> Cheers,
> Ivan
> 
> On 2025/4/11 04:16, Mario Limonciello wrote:
>> From: Mario Limonciello <mario.limonciello@amd.com>
>>
>> Modern machines that ship with Microsoft Security Levels enabled
>> will lock down SVM.  This is by design, so decrease existing failure
>> to 'advice' instead.
>>
>> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
>> ---
>>   src/cpu/virt/virt_svm.c | 4 +---
>>   1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/src/cpu/virt/virt_svm.c b/src/cpu/virt/virt_svm.c
>> index d86f54f4..8cee9aaf 100644
>> --- a/src/cpu/virt/virt_svm.c
>> +++ b/src/cpu/virt/virt_svm.c
>> @@ -77,9 +77,7 @@ void virt_check_svm(fwts_framework *fw)
>>               fwts_passed(fw, "Virtualization extensions supported and enabled by BIOS.");
>>               break;
>>           case 1:
>> -            fwts_failed(fw, LOG_LEVEL_MEDIUM,
>> -                "VirtDisabledByBIOS",
>> -                "Virtualization extensions supported but disabled by BIOS.");
>> +            fwts_advice(fw, "Virtualization extensions supported but disabled by BIOS.");
>>               break;
>>           default:
>>               fwts_log_error(fw, "Virtualization extensions check failed - cannot read msr.");
diff mbox series

Patch

diff --git a/src/cpu/virt/virt_svm.c b/src/cpu/virt/virt_svm.c
index d86f54f4..8cee9aaf 100644
--- a/src/cpu/virt/virt_svm.c
+++ b/src/cpu/virt/virt_svm.c
@@ -77,9 +77,7 @@  void virt_check_svm(fwts_framework *fw)
 			fwts_passed(fw, "Virtualization extensions supported and enabled by BIOS.");
 			break;
 		case 1:
-			fwts_failed(fw, LOG_LEVEL_MEDIUM,
-				"VirtDisabledByBIOS",
-				"Virtualization extensions supported but disabled by BIOS.");
+			fwts_advice(fw, "Virtualization extensions supported but disabled by BIOS.");
 			break;
 		default:
 			fwts_log_error(fw, "Virtualization extensions check failed - cannot read msr.");