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 X-Spam-Level: X-Spam-Status: No, score=-6.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CD7D5C433DB for ; Thu, 21 Jan 2021 15:48:27 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 5CAFC23356 for ; Thu, 21 Jan 2021 15:48:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5CAFC23356 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.72223.129872 (Exim 4.92) (envelope-from ) id 1l2cC4-0000YW-LM; Thu, 21 Jan 2021 15:48:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 72223.129872; Thu, 21 Jan 2021 15:48:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1l2cC4-0000YP-IO; Thu, 21 Jan 2021 15:48:20 +0000 Received: by outflank-mailman (input) for mailman id 72223; Thu, 21 Jan 2021 15:48:19 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1l2cC3-0000YI-Jv for xen-devel@lists.xenproject.org; Thu, 21 Jan 2021 15:48:19 +0000 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 529702e7-24f8-492a-90bb-7da796076fbf; Thu, 21 Jan 2021 15:48:18 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id D0F8523A5C for ; Thu, 21 Jan 2021 15:48:17 +0000 (UTC) Received: by mail-lj1-f169.google.com with SMTP id b10so3014402ljp.6 for ; Thu, 21 Jan 2021 07:48:17 -0800 (PST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 529702e7-24f8-492a-90bb-7da796076fbf DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1611244098; bh=ESCY3rt1UpVAToMmeAThDINvSacKiOsK2nc/NRoNF9g=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=LCFe42rTpo0PlaukO40aoasQL5/Qys43MShy5ZOg+JcG27AZaNRJ4cHu3ZE/cf8rR HIq5i0dftrTxshUnv+icHC5DHyTHfgXx2miR6yKQvenRHR5EcVuOpasmEc7yPQPVKD cwEyOANH8KznmYsj7P/LmxN8ew+znCkYwD6N0a4Tn3GZxCRNczrWFg3Bw2fLc+J8b0 mk+EobIZoCcxbqX8JNLKcWwjnfwQR3O98R8GTEtgLU8u20ZLIEKiWn8pxnDTKeDO9I oRgIbCp6Cch6hzf1mS9uVrtxlnUuCLlYvc71A4V2HcSXBy2GIVc5mXErflL3r+khjI CV+PqF7WZ5l5A== X-Gm-Message-State: AOAM533lDmoTwDoJRLlGxchr6FarOViVXYdNLha9vrcOuGAfK2ilPecY Fj0B3QpSKskiHA/Ob+rqxeL1PwC7FZ3T1MyDNg== X-Google-Smtp-Source: ABdhPJxClIBHDNh0ezMtBn3tEIUpA6A69KltrTNKbOdslOUCg3ST6RYu/puKZCvzOeFiwKhVG1uu2/TgGhoFpNLSPDU= X-Received: by 2002:a17:906:958f:: with SMTP id r15mr70711ejx.360.1611244095545; Thu, 21 Jan 2021 07:48:15 -0800 (PST) MIME-Version: 1.0 References: <20210106034124.30560-1-tientzu@chromium.org> <20210106034124.30560-6-tientzu@chromium.org> <20210120165348.GA220770@robh.at.kernel.org> <313f8052-a591-75de-c4c2-ee9ea8f02e7f@arm.com> In-Reply-To: From: Rob Herring Date: Thu, 21 Jan 2021 09:48:03 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH v3 5/6] dt-bindings: of: Add restricted DMA pool To: Robin Murphy Cc: Claire Chang , Michael Ellerman , Benjamin Herrenschmidt , Paul Mackerras , Joerg Roedel , Will Deacon , Frank Rowand , Konrad Rzeszutek Wilk , Boris Ostrovsky , Juergen Gross , Stefano Stabellini , Christoph Hellwig , Marek Szyprowski , Grant Likely , Heinrich Schuchardt , Thierry Reding , Ingo Molnar , Thiago Jung Bauermann , Peter Zijlstra , Greg Kroah-Hartman , Saravana Kannan , "Wysocki, Rafael J" , Heikki Krogerus , Andy Shevchenko , Randy Dunlap , Dan Williams , Bartosz Golaszewski , devicetree@vger.kernel.org, "linux-kernel@vger.kernel.org" , linuxppc-dev , Linux IOMMU , xen-devel@lists.xenproject.org, Tomasz Figa , Nicolas Boichat Content-Type: text/plain; charset="UTF-8" On Wed, Jan 20, 2021 at 7:10 PM Robin Murphy wrote: > > On 2021-01-20 21:31, Rob Herring wrote: > > On Wed, Jan 20, 2021 at 11:30 AM Robin Murphy wrote: > >> > >> On 2021-01-20 16:53, Rob Herring wrote: > >>> On Wed, Jan 06, 2021 at 11:41:23AM +0800, Claire Chang wrote: > >>>> Introduce the new compatible string, restricted-dma-pool, for restricted > >>>> DMA. One can specify the address and length of the restricted DMA memory > >>>> region by restricted-dma-pool in the device tree. > >>> > >>> If this goes into DT, I think we should be able to use dma-ranges for > >>> this purpose instead. Normally, 'dma-ranges' is for physical bus > >>> restrictions, but there's no reason it can't be used for policy or to > >>> express restrictions the firmware has enabled. > >> > >> There would still need to be some way to tell SWIOTLB to pick up the > >> corresponding chunk of memory and to prevent the kernel from using it > >> for anything else, though. > > > > Don't we already have that problem if dma-ranges had a very small > > range? We just get lucky because the restriction is generally much > > more RAM than needed. > > Not really - if a device has a naturally tiny addressing capability that > doesn't even cover ZONE_DMA32 where the regular SWIOTLB buffer will be > allocated then it's unlikely to work well, but that's just crap system > design. Yes, memory pressure in ZONE_DMA{32} is particularly problematic > for such limited devices, but it's irrelevant to the issue at hand here. Yesterday's crap system design is today's security feature. Couldn't this feature make crap system design work better? > What we have here is a device that's not allowed to see *kernel* memory > at all. It's been artificially constrained to a particular region by a > TZASC or similar, and the only data which should ever be placed in that May have been constrained, but that's entirely optional. In the optional case where the setup is entirely up to the OS, I don't think this belongs in the DT at all. Perhaps that should be solved first. > region is data intended for that device to see. That way if it tries to > go rogue it physically can't start slurping data intended for other > devices or not mapped for DMA at all. The bouncing is an important part > of this - I forget the title off-hand but there was an interesting paper > a few years ago which demonstrated that even with an IOMMU, streaming > DMA of in-place buffers could reveal enough adjacent data from the same > page to mount an attack on the system. Memory pressure should be > immaterial since the size of each bounce pool carveout will presumably > be tuned for the needs of the given device. > > > In any case, wouldn't finding all the dma-ranges do this? We're > > already walking the tree to find the max DMA address now. > > If all you can see are two "dma-ranges" properties, how do you propose > to tell that one means "this is the extent of what I can address, please > set my masks and dma-range-map accordingly and try to allocate things > where I can reach them" while the other means "take this output range > away from the page allocator and hook it up as my dedicated bounce pool, > because it is Serious Security Time"? Especially since getting that > choice wrong either way would be a Bad Thing. Either we have some heuristic based on the size or we add some hint. The point is let's build on what we already have for defining DMA accessible memory in DT rather than some parallel mechanism. Rob