linux-kernel - Re: [RFC 01/14] x86/apic: Add new driver for Secure AVIC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1f57da63-cf29-c75d-af06-c2cd795f0b04@amd.com>
Date: Wed, 9 Oct 2024 08:15:42 -0500
From: Tom Lendacky <thomas.lendacky@....com>
To: Neeraj Upadhyay <Neeraj.Upadhyay@....com>, Borislav Petkov <bp@...en8.de>
Cc: linux-kernel@...r.kernel.org, tglx@...utronix.de, mingo@...hat.com,
 dave.hansen@...ux.intel.com, nikunj@....com, Santosh.Shukla@....com,
 Vasant.Hegde@....com, Suravee.Suthikulpanit@....com, David.Kaplan@....com,
 x86@...nel.org, hpa@...or.com, peterz@...radead.org, seanjc@...gle.com,
 pbonzini@...hat.com, kvm@...r.kernel.org
Subject: Re: [RFC 01/14] x86/apic: Add new driver for Secure AVIC

On 10/9/24 01:01, Neeraj Upadhyay wrote:
> 
> 
> On 10/9/2024 10:53 AM, Borislav Petkov wrote:
>> On Wed, Oct 09, 2024 at 07:26:55AM +0530, Neeraj Upadhyay wrote:
>>> As SECURE_AVIC feature is not supported (as reported by snp_get_unsupported_features())
>>> by guest at this patch in the series, it is added to SNP_FEATURES_IMPL_REQ here. The bit
>>> value within SNP_FEATURES_IMPL_REQ hasn't changed with this change as the same bit pos
>>> was part of MSR_AMD64_SNP_RESERVED_MASK before this patch. In patch 14 SECURE_AVIC guest
>>> support is indicated by guest.
>>
>> So what's the point of adding it to SNP_FEATURES_IMPL_REQ here? What does that
>> do at all in this patch alone? Why is this change needed in here?
>>
> 
> Before this patch, if hypervisor enables Secure AVIC  (reported in sev_status), guest would
> terminate in snp_check_features(). The reason for this is, SNP_FEATURES_IMPL_REQ had the Secure
> AVIC bit set before this patch, as that bit was part of MSR_AMD64_SNP_RESERVED_MASK 
> GENMASK_ULL(63, 18).
> 
> #define SNP_FEATURES_IMPL_REQ	(MSR_AMD64_SNP_VTOM |			\
> 				 ...
> 				 MSR_AMD64_SNP_RESERVED_MASK)
> 
> 
> 
> Adding MSR_AMD64_SNP_SECURE_AVIC_BIT (bit 18) to SNP_FEATURES_IMPL_REQ in this patch
> keeps that behavior intact as now with this change MSR_AMD64_SNP_RESERVED_MASK becomes
> GENMASK_ULL(63, 19).
> 
> 
>> IOW, why don't you do all the feature bit handling in the last patch, where it
>> all belongs logically?
>>
> 
> If we do that, then hypervisor could have enabled Secure AVIC support and the guest
> code at this patch won't catch the missing guest-support early and it can result in some
> unknown failures at later point during guest boot.

Won't the SNP_RESERVED_MASK catch it? You are just renaming the bit
position value, right? It was a 1 before and is still a 1. So the guest
will terminate if the hypervisor sets the Secure AVIC bit both before
and after this patch, right?

Thanks,
Tom

> 
> 
> - Neeraj
> 
>> In the last patch you can start *testing* for
>> MSR_AMD64_SNP_SECURE_AVIC_ENABLED *and* enforce it with SNP_FEATURES_PRESENT.
>>