From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f176.google.com (mail-qk1-f176.google.com [209.85.222.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3BB0E3A48CF for ; Tue, 12 May 2026 12:40:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.176 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778589630; cv=none; b=FPTvRJ5ZGl/n9Rq5xB3DNLugj3cXe7+IqmkQorsw0Ju9Jg3rq9TC7frsHt3zEX3OxjmPrYXKKyaUpwTdh6Z/VBI/aiQLU8vi7qi8EcT82287q9E1WgkYESxKWfkfKpTbqU015laAchJtQAkvjUTW2J5sKByNaJl0uiyHRsZ3mT8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778589630; c=relaxed/simple; bh=hkKtx+usdPUmf0nx42KiBOuHEN8nSPyFyyIr59g+ADc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=qv/W8pEmMiX/TQBlmN5j29aXzh5Bp3oYDABIsrYYDb00rghAO+s+wIGPmNVfmTM/KXFJJrY6pM9kOYCVFP1r6M/2qrwcwxwKz/gg3jAfuognAWwuk0dW+h0soE5jZ8XPierwmmKoKzqFpQnVAWUgN2aBI8nFKqespLU4h2P+7YA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca; spf=pass smtp.mailfrom=ziepe.ca; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b=CVhhS7Mj; arc=none smtp.client-ip=209.85.222.176 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="CVhhS7Mj" Received: by mail-qk1-f176.google.com with SMTP id af79cd13be357-8d736211595so384316785a.0 for ; Tue, 12 May 2026 05:40:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1778589618; x=1779194418; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=4lELg4tysIZjC4IAy9jg6iqJ6L2+JsLGKduxlfu78HE=; b=CVhhS7MjqAdthE0W/nq9Mko3zZUzKwbr6KxLNdiRsbdvRtp3jkImf8/4Dbb/AFN9tG /1mFBrDvMKLm2EWEcMa5CCvVGwutGFkx0iJci3MV2itHc+pt3+m5p2xqfLHZybcW7sW6 8EfEsDD7W6MDZNuBVdDWyCrN6m+9fsPmC0qv5pWEXNT2PU6SZf74CyzogltGllg61Hg2 tNmJvJp1jnAXVN5qmg20MAy3viyPyI4EOju+Pdvnf14OgHJMp5n0E9mu/xNnQ+XHKjqX FsS6E7kmnQgo+CRF/LY3g43Mwd+V9uI1G+kIRoLcjAxAUZFp7C2eY5eTDLKDCtgquNYj RtfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778589618; x=1779194418; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=4lELg4tysIZjC4IAy9jg6iqJ6L2+JsLGKduxlfu78HE=; b=BR3N83LILmG4+obTePKT4kbq9iKmO3+KXvs15v7rAtcxufUrUJLo+ALh+rwXFUvU1H O99Ixa/C2puiSCq2rYJGJCWNCkCNWcoheaXeFyXTP+f4nhFSlV/Y63nl9TpVFBlJL7u3 4jQQSacNkzypuYkaaRy9GduWGFM3SaKdDFeju9uOHyVA9UXAMXSmDo6D9V0Kk3VaL+wu e9MDB0Dla7ABKeuD4f7Pdnd46uR3SUmrWYM3UqbqpcRtHqZZTiTh1f0fN56TYDC8gBzZ zqMt5/KTRbnEtXrI82l3XlrVaWR5Vl3VCNgn1Op90SrFsIA3zx9YjAA6ppL7rtIsFa++ h2VQ== X-Forwarded-Encrypted: i=1; AFNElJ+hyMsglgzZxcoYxDxGq5qiLS+4xMaLeM0H1kpm4qWCnwFQARKzTOyXZRk4zZzXeNDZgjgWwL8OzfF2lzc=@vger.kernel.org X-Gm-Message-State: AOJu0YzIjLMEU6pDVdBuQP++d5PFZftc6EgGMQwnwK/GRylGqFC0atCA CMPBDyp/yMwq0F6zt5Ck+NK8cqplyWVMHqZrdKBDUw7zUVpUr8noy+kiPSj37CLk87w= X-Gm-Gg: Acq92OHvqXeTpcwFCPcgufM1GpDd5IziHyx4OHyZGpyanLgDMSmRFzcEHvSRgQMUh4u 5IGgXf0T3xSNPe1IWlT3k4EOfRVH5IvzqybBiYL562p3I7M0LiVPuKUHXNF6qkAY7WOh+GXjXOc yRLGYskyoCK525XEKf21DIRDjxbdz8TztMAvWAlia7so3i0IIg+KoweVk30Hlqoa5Az5vz5nLMv H7Rmr4a0bM87XwnAk5p2+hxkd64TLwfGP6+y4GQv6wUPESC8dYRdAzRIITU/ohj9SwERnVc+b1k j26hMlrCrDv+fXgPmVRBHCpKuxQbIj3/2HreHpfkw4ERNUABycahvePZJFguuJZF7vH7NQbTfxY 7/UR4m3j5Dsoq1HBW4Qjfg0NetQ1T49J53Ui4pkJAGoyJyh4vGdpHKNFwbFY8lmZE/MNnoi24gI msr+ohNvfzUn8qkUJIDg5fb2v6GsT+B+frI6d7e2YN1RMzFlG4vh4iOeDub58ngw/GHLOnJb6ob JnrfA== X-Received: by 2002:a05:620a:2887:b0:8eb:2aae:ef9c with SMTP id af79cd13be357-904d4f4b25amr4301047185a.27.1778589617549; Tue, 12 May 2026 05:40:17 -0700 (PDT) Received: from ziepe.ca (crbknf0213w-47-54-130-67.pppoe-dynamic.high-speed.nl.bellaliant.net. [47.54.130.67]) by smtp.gmail.com with ESMTPSA id af79cd13be357-907b87bd588sm1464542685a.29.2026.05.12.05.40.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 May 2026 05:40:16 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1wMmPH-00000005Aky-3Kl2; Tue, 12 May 2026 09:40:15 -0300 Date: Tue, 12 May 2026 09:40:15 -0300 From: Jason Gunthorpe To: Joonwon Kang Cc: robin.murphy@arm.com, Alexander.Grest@microsoft.com, amhetre@nvidia.com, baolu.lu@linux.intel.com, easwar.hariharan@linux.microsoft.com, iommu@lists.linux.dev, jacob.jun.pan@linux.intel.com, joro@8bytes.org, jpb@kernel.org, kees@kernel.org, kevin.tian@intel.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, nicolinc@nvidia.com, praan@google.com, smostafa@google.com, will@kernel.org Subject: Re: [PATCH RFC] iommu: Enable per-device SSID space for SVA Message-ID: <20260512124015.GU9285@ziepe.ca> References: <20260511132128.GM9285@ziepe.ca> <20260512095714.2518097-1-joonwonkang@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260512095714.2518097-1-joonwonkang@google.com> On Tue, May 12, 2026 at 09:57:14AM +0000, Joonwon Kang wrote: > > There is a bit more going on though, I think that is what Joonwon is > > mentioning by asking about ST64B and ST64BV. I *think* the answer is: > > > > - ST64B uses a posted write > > - ST64BV can be restricted so EL0 cannot execute it, it uses a > > non-posted write (AI tells me via EnASR) > > - ST64BV0 can be used by EL0, always uses a non-posted write, and always > > uses ACCDATA_EL1 > > > > Which is similar to Intel. > > Ah, I missed that ST64BV is currently being trapped to EL1 while ST64B is > not [1]. However, I am not sure if the trap is to disallow EL0 to use it. > Can it be instead to pass the response value of the non-posted write to > EL0 while using the EL0-given PASID as-is? If so, I believe EL0 still can > specify arbitrary PASID as it wants via ST64BV. I think if an OS implements things this way it is would security broken as far as ENQCMD compatible HW goes. > Since I guess ST64B* instructions are to serve generic purposes not only > for communication with accelerators with SIOV but also with any memory > location or device without SIOV, I am not sure if it is always okay to > make those instructions work the way Jason mentioned. The end point has to use the posted vs non-posted write distinction for security. > > The device only processes the PASID from a non-posted write, > > Regarding ST64B, are the ARM devices behind ARM SMMU v3 supposed to work > this way too? If not, EL0 can specify arbitrary PASID via ST64B with the > kernel today [1]. If you want ENQCMD compatible semantics then yes you have to do all of these things, it is part of the security design. Jason