From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f202.google.com (mail-pl1-f202.google.com [209.85.214.202]) (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 04F1D3630A5 for ; Tue, 12 May 2026 14:51:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.202 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778597502; cv=none; b=TaPCI1qxGl58RtqxYiZuOuSRqoGJCg+iFKpoM1k7nqe3tr43VbsC/of/NfSuaOjYkEz66fe1CQdPDJ4oBXKQ6jlTMHg/y9YIi6XhPbv5NzjnlEhGACd+Otgg+CEdT6RkRln69Hl/nr/vU+eyQBWnBVPOryke0/EFdcIFz3wXDw0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778597502; c=relaxed/simple; bh=pwHPn0uSXjalVS1fYzKE8yuC0M4roMdbtLUDDT/7QaY=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=WLif1yt+25PNatVmqMF2JDx6py3RfajJq7r8kBsjkebcLlinR3xZJi/PUZjeD72hhm1cRb/OehnoFW7oY+PuRXBV6TMyZWOrG9tM5eq9IWweQ2mq5AVrkjbOZP/6cSdSUy07ESZ3OqJL5A5iwusZl/DMvjykW44Sp8JyD0nFpDY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--joonwonkang.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=s1QRNozh; arc=none smtp.client-ip=209.85.214.202 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--joonwonkang.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="s1QRNozh" Received: by mail-pl1-f202.google.com with SMTP id d9443c01a7336-2ba224c3ffdso80560225ad.0 for ; Tue, 12 May 2026 07:51:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1778597500; x=1779202300; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=nxuiWLL/PSSpmcGZYa/jLPGBLLlN9600U6sYLEUkki8=; b=s1QRNozh0TKkKRrNJJp0DvjJSK8nLIMqmfILnpvgDk5d4J6eJfAmQUEpFR3eAKLz0N dyRWNLgxqzq6ju/RYQKk30hByvDHM5e5HkHT9HLk/3t9uCUXhdaIVMUw0Fi6jyR221XW PXnFc1Z98LKlhpCx6TTcCCbkHr1dtYD+yKNCV0ShVRhhKRIXqrNepF36eTmOTYwQTCHZ Rcg0/jDUFwIJADLlP6kdlEOSBeq0iHjm7L0WGE8ByF2hIxNalQ+rIweB/xXhPnvpmt+I TQrtPxL4/iYmwu5HGVUgcWzPAXwbB3MPO1yjdrU6oLAwA28SdADGksSW0O4kD9MkrNFC nPDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778597500; x=1779202300; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=nxuiWLL/PSSpmcGZYa/jLPGBLLlN9600U6sYLEUkki8=; b=HZPruHH5j61khSUCLeIYQa5sYBQHKfjcH1PlgellpuPDKTClNsUsrrC1rof1Wf46tC Wz6HnesX1Pcs+82k9U8bGE9BLfJFORFxdrh18nXHpMvkm6GsiDtKvjJhkTRIW7QQXm3I z0YZgu5U+h7jBpPYrIKNanboafLh5baEqpqG1F2/7C8ydxis4uZkwKgCyN9yObjnlX4N UQoiZ68xmVPZAX5osBotsJowI1NiOyRTejVFezD2W54qDI2F9iVmGeFG/pBEnlSHTfU3 FiJ7UUsJOLuUcw61sHxtn7yQx+UpSIl8sq6LJ+Qq1HgukVDa4bgDbr4XD2glzkCl8mRl aldg== X-Forwarded-Encrypted: i=1; AFNElJ8Zp5/ToFoy25MoR7+Q7vyzNuDyfDWk7oy/Y+WmrDS55GSSphIPf/qzL628xjxsqXjYfeTZSH0PqH1nWi0=@vger.kernel.org X-Gm-Message-State: AOJu0YwDblFbxf+SdcGzMiJY7ER/CUeJnl6S6uCUV1CD3v0igRuvIwPH ZfCa1fxOYcm3lzgkf1orFuX7Z2gveb/afNBisGPI3zbdf9mZo+ur9Enae86Od2dhftHwzOXpxeX UasJZeoXj/E3fE2U2w0l6pBeLfw== X-Received: from plhs10.prod.google.com ([2002:a17:903:320a:b0:2bc:bb08:92dc]) (user=joonwonkang job=prod-delivery.src-stubby-dispatcher) by 2002:a17:903:847:b0:2ba:fed:7891 with SMTP id d9443c01a7336-2bd01301994mr22890545ad.30.1778597499958; Tue, 12 May 2026 07:51:39 -0700 (PDT) Date: Tue, 12 May 2026 14:51:38 +0000 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: X-Mailer: git-send-email 2.54.0.563.g4f69b47b94-goog Message-ID: <20260512145138.3414002-1-joonwonkang@google.com> Subject: Re: [PATCH RFC] iommu: Enable per-device SSID space for SVA From: Joonwon Kang To: robin.murphy@arm.com Cc: 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, jgg@ziepe.ca, joonwonkang@google.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 Content-Type: text/plain; charset="UTF-8" > On 12/05/2026 1:40 pm, Jason Gunthorpe wrote: > > 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. > > Yes, I think it's rather the point that the EnALS/EnASR traps to EL1 > allow EL1 to sanitise the data that ST64B/ST64BV are sending, and do > exactly things like substituting a valid PASID. ST64BV0 offers a way of > doing so _without_ needing the overhead of trapping, but conversely that > needs the EnAS0 opt-in all the way down to indicate both EL1's awareness > of programming ACCDATA_EL1 appropriately and EL2/3's awareness of > context-switching it. > > I've not looked closely at what exactly the arm64 arch code is doing > today and how well it actually fits the expected ENQCMD usage model, but > I can well believe it might need a bit of tweaking. > > Thanks, > Robin. > > >> 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 Appreciate all your clarifications here. So, my understanding is that if our system does not support ST64BV and ST64BV0 or if our device does not distinguish between the posted write and the non-posted write regarding PASID, then we can lift the use of the global PASID space. Can I say this? If yes, I will create a new patch which checks for that case. It might as well add a new device tree property to represent if the device supports the posted write vs. non-posted write distinction. Thanks, Joonwon Kang