From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f50.google.com (mail-qv1-f50.google.com [209.85.219.50]) (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 C9DD743E9D0 for ; Tue, 20 Jan 2026 17:54:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768931698; cv=none; b=mxXaMqx8rrXbDQqPO5KRMO65tKTG69yzUEnmLFyGrPLyxvZunApEpl2K9ZoU4zAG1uzdU7hsyjIGSzLwS8entLWQbpNd62O7Rc7QYlh/aWHSmqjiMQC2j38tOIdp0w7TlJHx8RtUHBzGp9AT0whD0vPWyh8V8uucEBlcL4Ok2Ak= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768931698; c=relaxed/simple; bh=3CkIAY2zgjDsS1u7AFhV2JtGAbVvbQ/yIpO8LAhi9JY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=lXdUWwW3l7V9wXxGKmc+X/l6MJhTTCZWOqBS4mgKBbwYd5ZAvzrgcVsaCZS2sqIlVpkpGVnlTs2nCHhGhZQgJX3F7NFQZsbo+6icrBIaFVNv5tujoz+ZFQ5m7N+iLaEt9OYx0i1xcj2WekDl2tPibhlIwH2zaGQTqThWxR+eyw8= 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=bx6ePGe5; arc=none smtp.client-ip=209.85.219.50 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="bx6ePGe5" Received: by mail-qv1-f50.google.com with SMTP id 6a1803df08f44-88a2fe9e200so52534896d6.0 for ; Tue, 20 Jan 2026 09:54:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1768931696; x=1769536496; 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=8qAE5sNEY+vMBcgIGavaDhVYcx1nfMvjPQrHoPpTHaw=; b=bx6ePGe5y+FlQsdSUUA4wefpIW8WrBUFJdJlxa3ml/9JxUlMdplOSrl5laNY51QGuu dNdMmpIP2q5ppIGExIYKpnacHxvBsuiASF5QjfM4PyGAXbrLBOo1cqhsJfH8rOLJojFH NG0fV0kqt+SBL+9sY3McThziTvPoOQRY/2eirLjfn56kIK0O+PyYplhBPP7mloVrew5r 6sCAVZXIBmC8lxIzrftLGm1mLbvsFWLTXj2vGinkODskFRG87T5PI/rkE8KA1L9CWjlS QImtSlI+dW3ZsK4z/epnQS/VjSk39R8WaOChAbWhcSFELoKxcw8AFvFA3Yuq48mlknSA yRxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768931696; x=1769536496; 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=8qAE5sNEY+vMBcgIGavaDhVYcx1nfMvjPQrHoPpTHaw=; b=dDlBhT6oeJtH7KWc9zRhsKWjuaVi+1YXI9wL4TGbpecPOONVgwYMvyboROqbmY1oip 55y3zP4cfzQwlsczPZYQ0qJBVmpmLy0bZkTp4Sw/MWWYgw9ai1N+f2GPPkLpIVy7A7Xv igcppwZyKBitSXCoGiLfr+5ddgxHd7pXg5BtdHM2NBdV3he8y+7DnUHBXzTKo72ZJPuy +ik4J2aHu0iHR2FDqoryUmbd7kMEzI9/sRFAfbbJhSgXFjCvPQL6zsGBI5Htkng9sVQ7 IwavlEdQJRnxXM7v+VBt07VuC/fyHm/TIa5pN369wOqwoIeEokPpTZARYmZ5gSw6lFUo UDeQ== X-Forwarded-Encrypted: i=1; AJvYcCVeYu1QZ9N9PPY5jc6cDLmUgurCYYn6WgZ1AB96Yqs629AxBrmk+3qwzT9vWY3IBYpyDLleVMytmln0KSs=@vger.kernel.org X-Gm-Message-State: AOJu0Yx+/Z99CsDtQdxe7vEKYj/FfJhv1VkhYxPamEg5SF+4NSB+ol+r 01CW8VcxiU6eN/o9gChYF+LxY4a7TEwf/Ompnf926uAzrjYseRhpio5vYxCnJcPCJZE= X-Gm-Gg: AZuq6aIU8bQ8Lx8uECsbLH04rLa4eMLJbrTvS9nHILCNrQ9aunlmwUVEw9OhacgYOhZ 2TjveDK3avAYbCJYjkJRGqRr4MUTIYMNcIUIYw4B3UuAe6VIABZtyjs+VkXfXb5RfovtRLtcXlA I3DHcSTOpsUZJ7UX7m61rSHFNxxTcibL3sYbVNS1frJE5P3Zp3S1h/jlgom3UyMOOGbvJkF6Yx5 +7+FVOuHMQkMI0/+lY1nGnGa35ttlRMcg2Uqil13weJhxHEEY4e+NLtmL0sKLNb5IlJW1htRmX6 1ik6ufpsUBp4IivPfyBQwAdDp1TTxATsMSdwd/fYO+U6oMzv34Zmz9h9AC3giVgms1ystmVLri+ Lro4i3Xw1uV8iIYGms+PvWOZkr+HRqwTD1KEJjs2UzoEeb0AyGjdzoaJULT/M01MD9jXZiljMcI a+XYLyzUTEnfnTbFi2Mzd4oKrU1xZ852n80o+0xhG3jiDORJZgTpfpMLkWQV0WTmFzVsA= X-Received: by 2002:a05:6214:491:b0:888:586a:cd89 with SMTP id 6a1803df08f44-8942ddadc32mr222578076d6.34.1768931695638; Tue, 20 Jan 2026 09:54:55 -0800 (PST) Received: from ziepe.ca (hlfxns017vw-142-162-112-119.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.162.112.119]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8c6a7250a60sm1078459185a.31.2026.01.20.09.54.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Jan 2026 09:54:55 -0800 (PST) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1viFwM-00000005aRG-2tYc; Tue, 20 Jan 2026 13:54:54 -0400 Date: Tue, 20 Jan 2026 13:54:54 -0400 From: Jason Gunthorpe To: Robin Murphy Cc: Suzuki K Poulose , "Aneesh Kumar K.V" , linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-coco@lists.linux.dev, Catalin Marinas , will@kernel.org, steven.price@arm.com, Marek Szyprowski Subject: Re: [PATCH 1/2] dma-direct: Validate DMA mask against canonical DMA addresses Message-ID: <20260120175454.GA1325733@ziepe.ca> References: <20260120064255.179425-1-aneesh.kumar@kernel.org> <2a0b6d1b-875a-4075-8fc9-a8534afc9168@arm.com> <0da8b73c-5bec-44c3-9902-221a11142c34@arm.com> <20260120151127.GP961572@ziepe.ca> 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: On Tue, Jan 20, 2026 at 05:11:27PM +0000, Robin Murphy wrote: > > But you could make an argument that a trusted device won't DMA to > > shared memory, ie it would SWIOTLB to private memory if that is > > required. > > I don't think we can assume that any arbitrary trusted device is *never* > going to want to access shared memory in the Realm IPA space, Well, I can say it isn't supported with the DMA API we have today, so that's not *never* but at least for the present moment assuming that only private addresses are used with DMA would be consistent with the overall kernel capability. Certainly I think we have use cases for mixing traffic, and someone here is looking at what it would take to extend things to actually make it possible to reach into arbitrary shared memory with the DMA API.. > and while it might technically be possible for a private SWIOTLB > buffer to handle that, we currently only have infrastructure that > assumes the opposite (i.e. that SWIOTLB buffers are shared for > bouncing untrusted DMA to/from private memory). We also don't support T=1 devices with the current kernel either, and the required behavior is exactly what a normal non-CC kernel does today. Basically, SWIOTLB should not be allocating or using shared memory with a T=1 device at all, and I think that is a important thing to have in the code for security. Anyhow, I'm just saying either you keep the limit as we have now or if the limit is relaxed for T=1 then it would make sense to fixup SWIOTLB to do traditional bouncing to avoid high (shared) addresses. > Thus for now, saying we can only promise to support DMA if the > device can access the whole IPA space itself is accurate. Right, that is where things are right now, and I don't think we should move away from those code limitations unless there are mitigations like bouncing.. > > Otherwise these two limitations will exclude huge numbers of real > > devices from working with ARM CCA at all. > > Pretty sure the dependency on TDISP wins in that regard ;) You can use existing T=0 devices without TDISP And bolting a TDISP capable PCI IP onto a device with an addressing limit probably isn't going to fix the addressing limit. :( > However, assuming that Realms and RMMs might eventually come up with their > own attestation mechanisms for on-chip non-PCIe devices (and such devices > continue to have crippled DMA capabilities) The fabric isn't the only issue here, and even "PCIe" appearing devices don't necessarily run over real-PCIe and may have limited fabrics. There are enough important devices out there that have internal limitations, like registers and data structures that just cannot store the full 64 bit address space. HW folks have a big $$ incentive to take shortcuts like this.. > then the fact is still that DA requires an SMMU for S2, so at worst > there should always be the possibility for an RMM to offer S1 SMMU > support to the Realm, we're just not there yet. Having a S1 would help a T=1 device, but it doesn't do anything for the T=0 devices. The other answer is to expect the VMM to limit the IPA size so that the IO devices can reach the full address space. Jason