Hi Stefano,
> On 23 Sep 2020, at 18:41, Stefano Stabellini <sstabell...@kernel.org> wrote:
>
> On Wed, 23 Sep 2020, Bertrand Marquis wrote:
>>> On 23 Sep 2020, at 12:17, Julien Grall <jul...@xen.org> wrote:
>>> On 23/09/2020 11:50, Bertrand Marquis wrote:
>>>> Hi,
>>>>> On 23 Sep 2020, at 09:28, Julien Grall <jul...@xen.org> wrote:
>>>>>
>>>>> From: Julien Grall <jgr...@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 <jgr...@amazon.com>
>>>> Reviewed-by: Bertrand Marquis <bertrand.marq...@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
