| Message ID | 20200923082832.20038-1-julien@xen.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | SUPPORT.MD: Clarify the support state for the Arm SMMUv{1, 2} drivers | expand |
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 >
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,
> 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
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,
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.
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 >
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
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