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

[Bertrand Marquis <Bertrand.Marquis@xxxxxxx>]

Hi Stefano,

> On 23 Sep 2020, at 18:41, Stefano Stabellini <sstabellini@xxxxxxxxxx> wrote:
> 
> On Wed, 23 Sep 2020, Bertrand Marquis wrote:
>>> On 23 Sep 2020, at 12:17, Julien Grall <julien@xxxxxxx> wrote:
>>> On 23/09/2020 11:50, Bertrand Marquis wrote:
>>>> Hi,
>>>>> On 23 Sep 2020, at 09:28, Julien Grall <julien@xxxxxxx> wrote:
>>>>> 
>>>>> From: Julien Grall <jgrall@xxxxxxxxxx>
>>>>> 
>>>>> 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@xxxxxxxxxx>
>>>> Reviewed-by: Bertrand Marquis <bertrand.marquis@xxxxxxx>
>>> 
>>> 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