linux-kernel - RE: [PATCH v2 2/3] iommu/vt-d: Check FL and SL capability sanity in scalable mode

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 for Android: free password hash cracker in your pocket

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

Message-ID: <BN9PR11MB54332D919870D61308795C708CA79@BN9PR11MB5433.namprd11.prod.outlook.com>
Date:   Mon, 27 Sep 2021 01:12:30 +0000
From:   "Tian, Kevin" <kevin.tian@...el.com>
To:     Lu Baolu <baolu.lu@...ux.intel.com>, Joerg Roedel <joro@...tes.org>
CC:     "Raj, Ashok" <ashok.raj@...el.com>,
        "Liu, Yi L" <yi.l.liu@...el.com>,
        "iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v2 2/3] iommu/vt-d: Check FL and SL capability sanity in
 scalable mode

> From: Lu Baolu <baolu.lu@...ux.intel.com>
> Sent: Sunday, September 26, 2021 7:46 PM
> 
> An iommu domain could be allocated and mapped before it's attached to
> any
> device. This requires that in scalable mode, when the domain is allocated,
> the format (FL or SL) of the page table must be determined. In order to
> achieve this, the platform should support consistent SL or FL capabilities
> on all IOMMU's. This adds a check for this and aborts IOMMU probing if it
> doesn't meet this requirement.

Is this a must? Looks the requirement comes from how the current code
is implemented. It sets DOMAIN_FLAG_USE_FIRST_LEVEL flag in
alloc_domain. But actually the pgtable is not allocated until the 1st device
is attached. If this understanding is correct, you can also postpone the flag 
setting until pgtable is actually allocated.

of course how to handle inconsistent IOMMU capabilities is another 
orthogonal problem. Addressing it should not be only applied to SL/FL
difference. especially this patch doesn't check consistency. it just
checks that an IOMMU must support either SL or FL which doesn't
match the commit msg here.

> 
> Signed-off-by: Lu Baolu <baolu.lu@...ux.intel.com>
> ---
>  drivers/iommu/intel/cap_audit.h |  1 +
>  drivers/iommu/intel/cap_audit.c | 13 +++++++++++++
>  2 files changed, 14 insertions(+)
> 
> diff --git a/drivers/iommu/intel/cap_audit.h
> b/drivers/iommu/intel/cap_audit.h
> index 74cfccae0e81..d07b75938961 100644
> --- a/drivers/iommu/intel/cap_audit.h
> +++ b/drivers/iommu/intel/cap_audit.h
> @@ -111,6 +111,7 @@ bool intel_cap_smts_sanity(void);
>  bool intel_cap_pasid_sanity(void);
>  bool intel_cap_nest_sanity(void);
>  bool intel_cap_flts_sanity(void);
> +bool intel_cap_slts_sanity(void);
> 
>  static inline bool scalable_mode_support(void)
>  {
> diff --git a/drivers/iommu/intel/cap_audit.c
> b/drivers/iommu/intel/cap_audit.c
> index b12e421a2f1a..040e4ae0e42b 100644
> --- a/drivers/iommu/intel/cap_audit.c
> +++ b/drivers/iommu/intel/cap_audit.c
> @@ -163,6 +163,14 @@ static int cap_audit_static(struct intel_iommu
> *iommu, enum cap_audit_type type)
>  			check_irq_capabilities(iommu, i);
>  	}
> 
> +	/*
> +	 * If the system is sane to support scalable mode, either SL or FL
> +	 * should be sane.
> +	 */
> +	if (intel_cap_smts_sanity() &&
> +	    !intel_cap_flts_sanity() && !intel_cap_slts_sanity())
> +		return -EFAULT;
> +
>  out:
>  	rcu_read_unlock();
>  	return 0;
> @@ -203,3 +211,8 @@ bool intel_cap_flts_sanity(void)
>  {
>  	return ecap_flts(intel_iommu_ecap_sanity);
>  }
> +
> +bool intel_cap_slts_sanity(void)
> +{
> +	return ecap_slts(intel_iommu_ecap_sanity);
> +}
> --
> 2.25.1