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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7A14EC433EF for ; Fri, 22 Oct 2021 08:06:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6308A610EA for ; Fri, 22 Oct 2021 08:06:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232351AbhJVIIs (ORCPT ); Fri, 22 Oct 2021 04:08:48 -0400 Received: from mail.kernel.org ([198.145.29.99]:58712 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231923AbhJVIIp (ORCPT ); Fri, 22 Oct 2021 04:08:45 -0400 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (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 B0DA9610C8; Fri, 22 Oct 2021 08:06:28 +0000 (UTC) Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mdpZJ-000sJI-9D; Fri, 22 Oct 2021 09:06:25 +0100 Date: Fri, 22 Oct 2021 09:06:24 +0100 Message-ID: <87pmrxbi0v.wl-maz@kernel.org> From: Marc Zyngier To: Lu Baolu Cc: Sven Peter , iommu@lists.linux-foundation.org, Robin Murphy , Arnd Bergmann , Hector Martin , linux-kernel@vger.kernel.org, Alexander Graf , Mohamed Mediouni , Will Deacon , Alyssa Rosenzweig Subject: Re: [PATCH v3 4/6] iommu: Move IOMMU pagesize check to attach_device In-Reply-To: <106088e3-2928-dace-e1b6-e1e74ffec366@linux.intel.com> References: <20211019163737.46269-1-sven@svenpeter.dev> <20211019163737.46269-5-sven@svenpeter.dev> <9e25f2c0-d9d3-475d-e973-63be1891f9a5@linux.intel.com> <8735ovdbcv.wl-maz@kernel.org> <6a886030-cbc6-9e92-bf79-77b659da2915@linux.intel.com> <87wnm6bxx2.wl-maz@kernel.org> <106088e3-2928-dace-e1b6-e1e74ffec366@linux.intel.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: baolu.lu@linux.intel.com, sven@svenpeter.dev, iommu@lists.linux-foundation.org, robin.murphy@arm.com, arnd@kernel.org, marcan@marcan.st, linux-kernel@vger.kernel.org, graf@amazon.com, mohamed.mediouni@caramail.com, will@kernel.org, alyssa@rosenzweig.io X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 22 Oct 2021 03:52:38 +0100, Lu Baolu wrote: > > On 10/21/21 4:10 PM, Marc Zyngier wrote: > > On Thu, 21 Oct 2021 03:22:30 +0100, > > Lu Baolu wrote: > >> > >> On 10/20/21 10:22 PM, Marc Zyngier wrote: > >>> On Wed, 20 Oct 2021 06:21:44 +0100, > >>> Lu Baolu wrote: > >>>> > >>>> On 2021/10/20 0:37, Sven Peter via iommu wrote: > >>>>> + /* > >>>>> + * Check that CPU pages can be represented by the IOVA granularity. > >>>>> + * This has to be done after ops->attach_dev since many IOMMU drivers > >>>>> + * only limit domain->pgsize_bitmap after having attached the first > >>>>> + * device. > >>>>> + */ > >>>>> + ret = iommu_check_page_size(domain); > >>>>> + if (ret) { > >>>>> + __iommu_detach_device(domain, dev); > >>>>> + return ret; > >>>>> + } > >>>> > >>>> It looks odd. __iommu_attach_device() attaches an I/O page table for a > >>>> device. How does it relate to CPU pages? Why is it a failure case if CPU > >>>> page size is not covered? > >>> > >>> If you allocate a CPU PAGE_SIZE'd region, and point it at a device > >>> that now can DMA to more than what you have allocated because the > >>> IOMMU's own page size is larger, the device has now access to data it > >>> shouldn't see. In my book, that's a pretty bad thing. > >> > >> But even you enforce the CPU page size check here, this problem still > >> exists unless all DMA buffers are PAGE_SIZE aligned and sized, right? > > > > Let me take a CPU analogy: you have a page that contains some user > > data *and* a kernel secret. How do you map this page into userspace > > without leaking the kernel secret? > > > > PAGE_SIZE allocations are the unit of isolation, and this applies to > > both CPU and IOMMU. If you have allocated a DMA buffer that is less > > than a page, you then have to resort to bounce buffering, or accept > > that your data isn't safe. > > I can understand the problems when IOMMU page sizes is larger than CPU > page size. But the code itself is not clean. The vendor iommu drivers > know more hardware details than the iommu core. It looks odd that the > vendor iommu says "okay, I can attach this I/O page table to the > device", but the iommu core says "no, you can't" and rolls everything > back. If your IOMMU driver can do things behind the core's back and contradict the view that the core has, then it is probably time to fix your IOMMU driver and make the core aware of what is going on. Supported page sizes is one of these things. In general, keeping the IOMMU driver as dumb as possible is a worthy design goal, and this is why we have these abstractions. M. -- Without deviation from the norm, progress is not possible.