From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 46F30C2D0A8 for ; Wed, 23 Sep 2020 17:41:28 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id BCB342067B for ; Wed, 23 Sep 2020 17:41:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="ZnRirfUn" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BCB342067B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kL8lV-0000Jd-8Y; Wed, 23 Sep 2020 17:41:13 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kL8lT-0000JS-W2 for xen-devel@lists.xenproject.org; Wed, 23 Sep 2020 17:41:12 +0000 X-Inumbo-ID: b7778aa8-acd6-4908-ae98-1ab7a9e20434 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id b7778aa8-acd6-4908-ae98-1ab7a9e20434; Wed, 23 Sep 2020 17:41:11 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id CB01120665; Wed, 23 Sep 2020 17:41:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1600882870; bh=zUJihJz+o6DlJM8qcZnLGKsIGfKpb9M7lrA0vc+27Nw=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=ZnRirfUnSbrwJ3eVolZSxBWDwrUIk6JcbWzEsgc04bduIpLWJPqt2J4ROnJJbRcNe tYTSXN8oZSy2FKpl68xNn2lNjZF7GYgeJNHHP5blpXbPi5y9mHXR4jsucz7Nf+q0m1 zXLPKlSMav4A6g5ahY8K45H90yNT7D1Jc2tRz2Oc= Date: Wed, 23 Sep 2020 10:41:09 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Bertrand Marquis cc: Julien Grall , "open list:X86" , Julien Grall , Andrew Cooper , George Dunlap , Ian Jackson , Jan Beulich , Stefano Stabellini , Wei Liu Subject: Re: [PATCH] SUPPORT.MD: Clarify the support state for the Arm SMMUv{1, 2} drivers In-Reply-To: Message-ID: References: <20200923082832.20038-1-julien@xen.org> <1D6392F2-F4EC-4025-A793-22EABF85AA0E@arm.com> <3c64f36f-6b43-6f73-e344-70b084f1f505@xen.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Wed, 23 Sep 2020, Bertrand Marquis wrote: > > On 23 Sep 2020, at 12:17, Julien Grall wrote: > > On 23/09/2020 11:50, Bertrand Marquis wrote: > >> Hi, > >>> On 23 Sep 2020, at 09:28, Julien Grall wrote: > >>> > >>> From: Julien Grall > >>> > >>> 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 > >> Reviewed-by: Bertrand Marquis > > > > 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.