linux-kernel - Re: [PATCH v4 1/8] x86/sev: Prepare for using the RMPREAD instruction to access the RMP

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: <dab3e393-0e50-cf34-f187-1a6357ceacd2@amd.com>
Date: Fri, 25 Oct 2024 08:39:44 -0500
From: Tom Lendacky <thomas.lendacky@....com>
To: "Kalra, Ashish" <ashish.kalra@....com>, linux-kernel@...r.kernel.org,
 x86@...nel.org
Cc: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
 Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>,
 Michael Roth <michael.roth@....com>, Nikunj A Dadhania <nikunj@....com>,
 Neeraj Upadhyay <Neeraj.Upadhyay@....com>
Subject: Re: [PATCH v4 1/8] x86/sev: Prepare for using the RMPREAD instruction
 to access the RMP

On 10/25/24 04:00, Kalra, Ashish wrote:
> , 
> On 10/23/2024 1:41 PM, Tom Lendacky wrote:
>> The RMPREAD instruction returns an architecture defined format of an
>> RMP entry. This is the preferred method for examining RMP entries.
>>
>> In preparation for using the RMPREAD instruction, convert the existing
>> code that directly accesses the RMP to map the raw RMP information into
>> the architecture defined format.
>>
>> RMPREAD output returns a status bit for the 2MB region status. If the
>> input page address is 2MB aligned and any other pages within the 2MB
>> region are assigned, then 2MB region status will be set to 1. Otherwise,
>> the 2MB region status will be set to 0. For systems that do not support
>> RMPREAD, calculating this value would require looping over all of the RMP
>> table entries within that range until one is found with the assigned bit
>> set. Since this bit is not defined in the current format, and so not used
>> today, do not incur the overhead associated with calculating it.
>>
>> Signed-off-by: Tom Lendacky <thomas.lendacky@....com>
>> ---
>>  arch/x86/virt/svm/sev.c | 121 +++++++++++++++++++++++++++++-----------
>>  1 file changed, 87 insertions(+), 34 deletions(-)
>>
>> diff --git a/arch/x86/virt/svm/sev.c b/arch/x86/virt/svm/sev.c
>> index 0ce17766c0e5..4d095affdb4d 100644
>> --- a/arch/x86/virt/svm/sev.c
>> +++ b/arch/x86/virt/svm/sev.c

>>  
>> -	entry = get_rmpentry(pfn);
>> -	if (IS_ERR(entry))
>> -		return entry;
>> +	if (unlikely(pfn > rmptable_max_pfn))
> 
> rmptable_max_pfn is initialized in patch#5, shouldn't this patch be moved after patch #5 ?
> 
>> +		return ERR_PTR(-EFAULT);
>> +
>> +	return rmptable + pfn;
> 
> Again, rmptable is initialized/setup in patch#5, similarly shouldn't this patch be moved
> after patch #5 ?

rmptable_max_pfn is initialized in snp_rmptable_init(), as is rmptable.

Thanks,
Tom

> 
> Thanks,
> Ashish
>