Re: [PATCH] SUPPORT.MD: Clarify the support state for the Arm SMMUv{1, 2} drivers

From: Stefano Stabellini <sstabellini@kernel.org>
To: Bertrand Marquis <Bertrand.Marquis@arm.com>
Cc: Julien Grall <julien@xen.org>,
	 "open list:X86" <xen-devel@lists.xenproject.org>,
	 Julien Grall <jgrall@amazon.com>,
	 Andrew Cooper <andrew.cooper3@citrix.com>,
	 George Dunlap <george.dunlap@citrix.com>,
	Ian Jackson <iwj@xenproject.org>,
	 Jan Beulich <jbeulich@suse.com>,
	 Stefano Stabellini <sstabellini@kernel.org>,
	Wei Liu <wl@xen.org>
Subject: Re: [PATCH] SUPPORT.MD: Clarify the support state for the Arm SMMUv{1,  2} drivers
Date: Wed, 23 Sep 2020 10:41:09 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.21.2009231034510.1495@sstabellini-ThinkPad-T480s> (raw)
In-Reply-To: <C14129BD-09F3-4297-BBD6-9F3C5AA82FA7@arm.com>

On Wed, 23 Sep 2020, Bertrand Marquis wrote:
> > On 23 Sep 2020, at 12:17, Julien Grall <julien@xen.org> wrote:
> > On 23/09/2020 11:50, Bertrand Marquis wrote:
> >> Hi,
> >>> On 23 Sep 2020, at 09:28, Julien Grall <julien@xen.org> wrote:
> >>> 
> >>> From: Julien Grall <jgrall@amazon.com>
> >>> 
> >>> SMMUv{1, 2} are both marked as security supported, so we would
> >>> technically have to issue an XSA for any IOMMU security bug.
> >>> 
> >>> However, at the moment, device passthrough is not security supported
> >>> on Arm and there is no plan to change that in the next few months.
> >>> 
> >>> Therefore, mark Arm SMMUv{1, 2} as supported but not security supported.
> >>> 
> >>> Signed-off-by: Julien Grall <jgrall@amazon.com>
> >> Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
> > 
> > Thanks!
> > 
> >> We will publish in the next week a first implementation of SMMUv3 support which might make sense to have fully Supported.
> > 
> > I am not sure whether you include security supported in your "fully supported"
> 
> If we something is missing we will be happy to fix it to reach this goal.
> 
> > 
> > However, I would consider to follow the same model as we did with the IPMMU. The driver would first be marked as a technical preview to allow more testing in the community.
> 
> I was not meaning to have this at the very beginning.
> More that it make more sense in general to have SMMUv3 with 2 level of page table supporting this then old SMMU versions.

Just as a clarification, the distinction that we are making here is not
to "downgrade" SMMUv1/2, but to clarify that it is not security
supported. SMMUv1/2 is still fully supported.

Security support means that the security team will attempt to fix under
closed door any bugs affecting it, and pre-disclose the fix at the
appropriate time before making it fully public. It is a pretty heavy
process in comparison to normal bug fixing and in the case of the SMMU
doesn't make a lot of sense because device assignment in general is
currently not security supported.

For SMMUv3, I think it makes sense for it to possibly start as "tech
preview" for one release or two, then become "supported, not security
supported".

Of course if one day we make the decision to turn device assignment
security supported, then it makes sense to also change one or more SMMU
drivers to security supported.