linux-kernel - Re: [PATCH v6 05/10] x86/sme: Avoid SME/SVE related checks on non-SME/SVE platforms

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] [day] [month] [year] [list]

Message-ID: <bc0e54cb-317f-4d02-8591-5b04aba9d0dd@amd.com>
Date: Tue, 27 Feb 2024 09:11:00 -0600
From: Tom Lendacky <thomas.lendacky@....com>
To: Ard Biesheuvel <ardb@...nel.org>
Cc: Ard Biesheuvel <ardb+git@...gle.com>, linux-kernel@...r.kernel.org,
 Kevin Loughlin <kevinloughlin@...gle.com>,
 Dionna Glaze <dionnaglaze@...gle.com>, Thomas Gleixner <tglx@...utronix.de>,
 Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
 Dave Hansen <dave.hansen@...ux.intel.com>, Andy Lutomirski
 <luto@...nel.org>, Brian Gerst <brgerst@...il.com>
Subject: Re: [PATCH v6 05/10] x86/sme: Avoid SME/SVE related checks on
 non-SME/SVE platforms

On 2/27/24 08:55, Ard Biesheuvel wrote:
> On Mon, 26 Feb 2024 at 22:38, Tom Lendacky <thomas.lendacky@....com> wrote:
>>
>> On 2/26/24 08:29, Ard Biesheuvel wrote:
>>> From: Ard Biesheuvel <ardb@...nel.org>
>>>

>>> -void __init sme_enable(struct boot_params *bp)
>>> +void __head sme_enable(struct boot_params *bp)
>>>    {
>>>        const char *cmdline_ptr, *cmdline_arg, *cmdline_on;
>>>        unsigned int eax, ebx, ecx, edx;
>>>        unsigned long feature_mask;
>>>        unsigned long me_mask;
>>>        char buffer[16];
>>> -     bool snp;
>>>        u64 msr;
>>>
>>> -     snp = snp_init(bp);
>>
>> The snp_init() call is here because the SNP CPUID table needs to be
>> established before the below CPUID instruction is executed. This can't be
>> moved.
>>
> 
> Yeah, good point. I didn't spot this in my SEV-SNP boot testing,
> presumably because the firmware's VC handler is still active in my
> case, but this isn't guaranteed, e.g., when booting via the
> decompressor, or when using 5-level paging.

Actually, the kernel's do_vc_no_ghcb() is the handler that gets invoked. 
Since the CPUID table is not initialized, -EOPNOTSUPP is returned from 
snp_cpuid(), which results in the handler using the MSR protocol to get 
the CPUID information from the hypervisor - which we don't want for SNP in 
this situation.

Thanks,
Tom


> 
> Thanks for the review.