linux-kernel - Re: [PATCH v10 06/50] x86/sev: Add the host SEV-SNP initialization support

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]

Date:   Tue, 7 Nov 2023 15:21:29 -0600
From:   "Kalra, Ashish" <ashish.kalra@....com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     Michael Roth <michael.roth@....com>, kvm@...r.kernel.org,
        linux-coco@...ts.linux.dev, linux-mm@...ck.org,
        linux-crypto@...r.kernel.org, x86@...nel.org,
        linux-kernel@...r.kernel.org, tglx@...utronix.de, mingo@...hat.com,
        jroedel@...e.de, thomas.lendacky@....com, hpa@...or.com,
        ardb@...nel.org, pbonzini@...hat.com, seanjc@...gle.com,
        vkuznets@...hat.com, jmattson@...gle.com, luto@...nel.org,
        dave.hansen@...ux.intel.com, slp@...hat.com, pgonda@...gle.com,
        peterz@...radead.org, srinivas.pandruvada@...ux.intel.com,
        rientjes@...gle.com, dovmurik@...ux.ibm.com, tobin@....com,
        vbabka@...e.cz, kirill@...temov.name, ak@...ux.intel.com,
        tony.luck@...el.com, marcorr@...gle.com,
        sathyanarayanan.kuppuswamy@...ux.intel.com, alpergun@...gle.com,
        jarkko@...nel.org, nikunj.dadhania@....com, pankaj.gupta@....com,
        liam.merwick@...cle.com, zhi.a.wang@...el.com,
        Brijesh Singh <brijesh.singh@....com>
Subject: Re: [PATCH v10 06/50] x86/sev: Add the host SEV-SNP initialization
 support

On 11/7/2023 2:27 PM, Borislav Petkov wrote:
> On Tue, Nov 07, 2023 at 08:19:31PM +0100, Borislav Petkov wrote:
>> Arch code does not call drivers - arch code sets up the arch and
>> provides facilities which the drivers use.
> 
> IOW (just an example diff):
> 
> diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c
> index 1c9924de607a..00cdbc844961 100644
> --- a/drivers/iommu/amd/init.c
> +++ b/drivers/iommu/amd/init.c
> @@ -3290,6 +3290,7 @@ static int __init state_next(void)
>   		break;
>   	case IOMMU_ENABLED:
>   		register_syscore_ops(&amd_iommu_syscore_ops);
> +		amd_iommu_snp_enable();
>   		ret = amd_iommu_init_pci();
>   		init_state = ret ? IOMMU_INIT_ERROR : IOMMU_PCI_INIT;
>   		break;
> @@ -3814,16 +3815,6 @@ int amd_iommu_snp_enable(void)
>   		return -EINVAL;
>   	}
>   
> -	/*
> -	 * Prevent enabling SNP after IOMMU_ENABLED state because this process
> -	 * affect how IOMMU driver sets up data structures and configures
> -	 * IOMMU hardware.
> -	 */
> -	if (init_state > IOMMU_ENABLED) {
> -		pr_err("SNP: Too late to enable SNP for IOMMU.\n");
> -		return -EINVAL;
> -	}
> -
>   	amd_iommu_snp_en = check_feature_on_all_iommus(FEATURE_SNP);
>   	if (!amd_iommu_snp_en)
>   		return -EINVAL;
> 
> and now you only need to line up snp_rmptable_init() after IOMMU init
> instead of having it be a fs_initcall which happens right after
> pci_subsys_init() so that PCI is there but at the right time when iommu
> init state is at IOMMU_ENABLED but no later because then it is too late.
> 
> And there you need to test amd_iommu_snp_en which is already exported
> anyway.
> 
> Ok?
> 

No, this is not correct as this will always enable SNP support on IOMMU 
even when SNP support is not supported and enabled on the platform, and 
then we will do stuff like forcing IOMMU v1 pagetables which we really 
don't want to do if SNP is not supported and enabled on the platform.

That's what snp_rmptable_init() calling amd_iommu_snp_enable() ensures 
that SNP on IOMMU is *only* enabled when platform/arch support for it is 
detected and enabled.

And isn't IOMMU driver always going to be built-in and isn't it part of 
the platform support (not arch code, but surely platform specific code)?
(IOMMU enablement is requirement for SNP).

Thanks,
Ashish