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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id F0126CA0ED3 for ; Mon, 2 Sep 2024 10:20:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To: Content-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=uv5FZr6rZ6VqzNNSiX6mzSa07qcjEjBpw1DOUryq6jM=; b=JSONgGEB28zrypdigLg8DSuGjn rqjiUL8qWtFhziWlF65EeYbV3Bcy8vMCaJIv3uKhJ0wHf4MN5aEIRjI1WwjQ/iVRvBmYixJd8OObv Hd3Yp93ZLsZO58TJxmAPK26RitQSbMbdyEHTAIwOKjTU65XTEzkLc1ogFiVXbNTCvwfcicNbIoo1P ZzFafyfSR5bafaEtisSJWtJHDx1IdcePHokt1B3+rPlLWBBTQ4LVSVW3V030DnsIe0TRMJr5rUvEw 5zKDzjijZR8guhkbV++tksjsEWq3AhtbHHIpFslfAfBB//Byv0r1vVO9DAE9E3fdsE1hIEGJxCdYm Yw7blRMQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sl4A3-0000000DsjL-24XJ; Mon, 02 Sep 2024 10:19:51 +0000 Received: from mail-wm1-x335.google.com ([2a00:1450:4864:20::335]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sl41q-0000000DqYy-3sUl for linux-arm-kernel@lists.infradead.org; Mon, 02 Sep 2024 10:11:24 +0000 Received: by mail-wm1-x335.google.com with SMTP id 5b1f17b1804b1-429d1a9363aso64935e9.1 for ; Mon, 02 Sep 2024 03:11:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1725271881; x=1725876681; darn=lists.infradead.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=uv5FZr6rZ6VqzNNSiX6mzSa07qcjEjBpw1DOUryq6jM=; b=VuArpJKHSu2A1C/qy5ATpbxkGyS6bdEzz8pacTmo7flN60IObQ1FOlbURcA//8vvHG w0WNkgFpq0k+4rZU42yyPDd8YqtDXxrihMgB4740RT9DXosMwte5hfY8G+502cm4udNV E57ZHtdc5hP9L/a3mluybwbtJjTcjSj1v3UpYP6XNXGERFQGFX/0Nbih86yo3wCOQ8aL A8hHVKQAaaliRdYJVV0SgWntNmAzBmslYsFgfwELiY2WgUY2iZ6retf+zYQiissy1qrB 1z5yOLstJQ5Fg1HajlbmfTQwdg8t/jQidmIbtOXhoLNhuKKwgjvzqSVr5mqz3+ViATFK 2RKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725271881; x=1725876681; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=uv5FZr6rZ6VqzNNSiX6mzSa07qcjEjBpw1DOUryq6jM=; b=j/BY6+ETE5B6+zGaPoh2I42demDrERdmfHv2raz3DhMz6iYUzFuiWaS3+uiY0vqyDz yV5441Vj+um8be6Y0upCWv9W2B5V3uMPx1dRSsnDE6XFbF4yAbLf+z+3zC3zIJU0oLil cQdLGrR+8/9EEGw/cMtTw9vYW4gBnpoZb61Ae8pcdYn1WWbkoNRKAXo+IHUGUUuDxuoe 1K7IEVVEGCT0bsGV2adFl9pTkJ8hViZ/OW+ucZu52hYxLcWtJXA6F0G+xyZXvd/jUqbR 3G5svlLIl0UBltrrwXqCsAWgCOXxGesH4JrleEp8qLAioBlG5yLwb+GVsFTUKjrzYm36 hZqw== X-Forwarded-Encrypted: i=1; AJvYcCUrqEyhhfvX+p3govDaozIvaMn6kb/svKnirwG7+QwdBs8JZDxE/qth0dhbfYQ8jqmdQnJO2fUFheRW98SfcR+D@lists.infradead.org X-Gm-Message-State: AOJu0Yw012RFCJOakGxYRALn35gxjM0STx+pWcuQSs198vGtMvRRNNQL LQpZqaQHZCW/a3aEVGpFkyFsN+sM5tPCtKUZUxJ9LorAadw1dwUE7zfzF3KBwg== X-Google-Smtp-Source: AGHT+IEUVqSYP8vAntRCNYY+qDlbdxLNJoRSmxfSPQkZYaqM46by3fcwoSLExd+dVfdZhFC6FNtXRg== X-Received: by 2002:a05:600c:c15:b0:42b:8ff7:9cfe with SMTP id 5b1f17b1804b1-42c787683a2mr2004925e9.1.1725271880837; Mon, 02 Sep 2024 03:11:20 -0700 (PDT) Received: from google.com (109.36.187.35.bc.googleusercontent.com. [35.187.36.109]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-42bba3f2875sm111687515e9.41.2024.09.02.03.11.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Sep 2024 03:11:20 -0700 (PDT) Date: Mon, 2 Sep 2024 10:11:16 +0000 From: Mostafa Saleh To: Jason Gunthorpe Cc: acpica-devel@lists.linux.dev, Hanjun Guo , iommu@lists.linux.dev, Joerg Roedel , Kevin Tian , kvm@vger.kernel.org, Len Brown , linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Lorenzo Pieralisi , "Rafael J. Wysocki" , Robert Moore , Robin Murphy , Sudeep Holla , Will Deacon , Alex Williamson , Eric Auger , Jean-Philippe Brucker , Moritz Fischer , Michael Shavit , Nicolin Chen , patches@lists.linux.dev, Shameerali Kolothum Thodi Subject: Re: [PATCH v2 6/8] iommu/arm-smmu-v3: Support IOMMU_GET_HW_INFO via struct arm_smmu_hw_info Message-ID: References: <0-v2-621370057090+91fec-smmuv3_nesting_jgg@nvidia.com> <6-v2-621370057090+91fec-smmuv3_nesting_jgg@nvidia.com> <20240830171602.GX3773488@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20240830171602.GX3773488@nvidia.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240902_031122_987137_61BEA356 X-CRM114-Status: GOOD ( 31.57 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Aug 30, 2024 at 02:16:02PM -0300, Jason Gunthorpe wrote: > On Fri, Aug 30, 2024 at 03:23:41PM +0000, Mostafa Saleh wrote: > > > +/** > > > + * struct iommu_hw_info_arm_smmuv3 - ARM SMMUv3 hardware information > > > + * (IOMMU_HW_INFO_TYPE_ARM_SMMUV3) > > > + * > > > + * @flags: Must be set to 0 > > > + * @__reserved: Must be 0 > > > + * @idr: Implemented features for ARM SMMU Non-secure programming interface > > > + * @iidr: Information about the implementation and implementer of ARM SMMU, > > > + * and architecture version supported > > > + * @aidr: ARM SMMU architecture version > > > + * > > > + * For the details of @idr, @iidr and @aidr, please refer to the chapters > > > + * from 6.3.1 to 6.3.6 in the SMMUv3 Spec. > > > + * > > > + * User space should read the underlying ARM SMMUv3 hardware information for > > > + * the list of supported features. > > > + * > > > + * Note that these values reflect the raw HW capability, without any insight if > > > + * any required kernel driver support is present. Bits may be set indicating the > > > + * HW has functionality that is lacking kernel software support, such as BTM. If > > > + * a VMM is using this information to construct emulated copies of these > > > + * registers it should only forward bits that it knows it can support. > > > + * > > > + * In future, presence of required kernel support will be indicated in flags. > > > + */ > > > +struct iommu_hw_info_arm_smmuv3 { > > > + __u32 flags; > > > + __u32 __reserved; > > > + __u32 idr[6]; > > > + __u32 iidr; > > > + __u32 aidr; > > > +}; > > There is a ton of information here, I think we might need to santitze the > > values for what user space needs to know (that's why I was asking about qemu) > > also SMMU_IDR4 is implementation define, not sure if we can unconditionally > > expose it to userspace. > > What is the harm? Does exposing IDR data to userspace in any way > compromise the security or integrity of the system? > > I think no - how could it? I don’t see a clear harm or exploit with exposing IDRs, but IMHO we should deal with userspace with the least privilege principle and only expose what user space cares about (with sanitised IDRs or through another mechanism) For example, KVM doesn’t allow reading reading the CPU system registers to know if SVE(or other features) is supported but hides that by a CAP in KVM_CHECK_EXTENSION > > As the comments says, the VMM should not just blindly forward this to > a guest! I don't think the kernel should trust userspace. > > The VMM needs to make its own IDR to reflect its own vSMMU > capabilities. It can refer to the kernel IDR if it needs to. > > So, if the kernel is going to limit it, what criteria would you > propose the kernel use? I agree that the VMM would create a virtual IDR for guest, but that doesn't have to be directly based on the physical one (same as CPU). Thanks, Mostafa > > Jason