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

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

[Julien Grall]

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>

---

Cc: Bertrand Marquis <Bertrand.Marquis@arm.com>
---
 SUPPORT.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/SUPPORT.md b/SUPPORT.md
index 25987ec1dfb6..f35943a432f7 100644
--- a/SUPPORT.md
+++ b/SUPPORT.md
@@ -62,8 +62,8 @@ supported in this document.
 
     Status, AMD IOMMU: Supported
     Status, Intel VT-d: Supported
-    Status, ARM SMMUv1: Supported
-    Status, ARM SMMUv2: Supported
+    Status, ARM SMMUv1: Supported, not security supported
+    Status, ARM SMMUv2: Supported, not security supported
     Status, Renesas IPMMU-VMSA: Supported, not security supported
 
 ### ARM/GICv3 ITS
-- 
2.17.1

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

[Bertrand Marquis]

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>

We will publish in the next week a first implementation of SMMUv3 support which might make sense to have fully Supported.

Cheers,
Bertrand

> 
> ---
> 
> Cc: Bertrand Marquis <Bertrand.Marquis@arm.com>
> ---
> SUPPORT.md | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/SUPPORT.md b/SUPPORT.md
> index 25987ec1dfb6..f35943a432f7 100644
> --- a/SUPPORT.md
> +++ b/SUPPORT.md
> @@ -62,8 +62,8 @@ supported in this document.
> 
>     Status, AMD IOMMU: Supported
>     Status, Intel VT-d: Supported
> -    Status, ARM SMMUv1: Supported
> -    Status, ARM SMMUv2: Supported
> +    Status, ARM SMMUv1: Supported, not security supported
> +    Status, ARM SMMUv2: Supported, not security supported
>     Status, Renesas IPMMU-VMSA: Supported, not security supported
> 
> ### ARM/GICv3 ITS
> -- 
> 2.17.1
> 

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

[Julien Grall]

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"

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.

Cheers,

-- 
Julien Grall

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

[Bertrand Marquis]

> 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.

Cheers
Bertrand

> 
> Cheers,
> 
> -- 
> Julien Grall

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

[Julien Grall]

On 23/09/2020 14:55, Bertrand Marquis wrote:
>> On 23 Sep 2020, at 12:17, Julien Grall <julien@xen.org> wrote:
> More that it make more sense in general to have SMMUv3 with 2 level of page table supporting this then old SMMU versions.

Both driver are equally important. I wouldn't discard SMMUv2 just 
because there is a new shiny version.

I also have some concerns with the SMMUv3. They are pretty similar to 
the GICv3 ITS as both use a shared ring for the commands.

Cheers,

-- 
Julien Grall

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

[Stefano Stabellini]

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.

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

[Stefano Stabellini]

On Wed, 23 Sep 2020, Julien Grall 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>

Acked-by: Stefano Stabellini <sstabellini@kernel.org>


> ---
> 
> Cc: Bertrand Marquis <Bertrand.Marquis@arm.com>
> ---
>  SUPPORT.md | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/SUPPORT.md b/SUPPORT.md
> index 25987ec1dfb6..f35943a432f7 100644
> --- a/SUPPORT.md
> +++ b/SUPPORT.md
> @@ -62,8 +62,8 @@ supported in this document.
>  
>      Status, AMD IOMMU: Supported
>      Status, Intel VT-d: Supported
> -    Status, ARM SMMUv1: Supported
> -    Status, ARM SMMUv2: Supported
> +    Status, ARM SMMUv1: Supported, not security supported
> +    Status, ARM SMMUv2: Supported, not security supported
>      Status, Renesas IPMMU-VMSA: Supported, not security supported
>  
>  ### ARM/GICv3 ITS
> -- 
> 2.17.1
> 

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

[Bertrand Marquis]

Hi Stefano,

> On 23 Sep 2020, at 18:41, Stefano Stabellini <sstabellini@kernel.org> wrote:
> 
> 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.

Thanks for the clarification.
Of course i never wanted to remove or downgrade SMMUv1/2 support,.

> 
> 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".

Ok.

> 
> 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.

Make sense yes, one does not go with the other.

Regards
Bertrand