linux-kernel - Re: [PATCH v3 2/8] x86/sev: Add support for the RMPREAD instruction

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: <f5383cb1-0c0e-eb8a-e3b5-bb7d5a80fcbd@amd.com>
Date: Thu, 17 Oct 2024 11:24:06 -0500
From: Tom Lendacky <thomas.lendacky@....com>
To: Borislav Petkov <bp@...en8.de>
Cc: linux-kernel@...r.kernel.org, x86@...nel.org,
 Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
 Dave Hansen <dave.hansen@...ux.intel.com>,
 Michael Roth <michael.roth@....com>, Ashish Kalra <ashish.kalra@....com>
Subject: Re: [PATCH v3 2/8] x86/sev: Add support for the RMPREAD instruction

On 10/17/24 10:26, Borislav Petkov wrote:
> On Mon, Sep 30, 2024 at 10:22:10AM -0500, Tom Lendacky wrote:
>> +	if (cpu_feature_enabled(X86_FEATURE_RMPREAD)) {
>> +		int ret;
>> +
>> +		asm volatile(".byte 0xf2, 0x0f, 0x01, 0xfd"
>> +			     : "=a" (ret)
>> +			     : "a" (pfn << PAGE_SHIFT), "c" (entry)
>> +			     : "memory", "cc");
>> +
>> +		return ret;
>> +	}
>> +
>>  	e = __get_rmpentry(pfn);
> 
> So dump_rmpentry() still calls this but it doesn't require the newly added
> services of RMPREAD and so this is looking to be disambiguated: a function
> which gives you the entry coming from RMPREAD, I guess the architectural one,
> and the other one.

Right, because for debugging purposes we want to dump the raw RMP entry
that is in the RMP table, not just the information returned by RMPREAD
(since RMPREAD doesn't return everything defined in the RMP entry).

This is why dump_rmpentry() merely prints out the RMP entry as two u64
values.

> 
> IOW, I am still unclear on the nomenclature:
> 
> The _raw* entries do not come from the insn but then what's the raw-ness about
> them?

The raw-ness is that it is the actual data in the RMP table. The reason
for RMPREAD is because there is no guarantee that the raw data won't be
reformatted in a future program, which is why we only allow access to
the RMP entry for Milan and Genoa, where the format is known and the same.

Thanks,
Tom

> 
> This convention sounds weird as it is now, I'd say.
> 
> Thx.
>