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=-5.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 73ADFC07E95 for ; Wed, 7 Jul 2021 20:02:58 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 34B3261CC2 for ; Wed, 7 Jul 2021 20:02:58 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 34B3261CC2 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=qgBhUsetDK0lgzaqlyxp3/L2Wye/oEGULn0BA3FJxAo=; b=ufb5vMRJhs+5UA VisBtbBG2pIDZ9AZ5ZDnwJGdwRwTKzXZLKT4Po2vu8efbyUzkmopThMZEltIwGLA9H6HS0FBoThRP tWqcZcq5iY4PxsUzNry2RN+Nw5Wg6VX8WmZFE7cfmn+dqOFrTT4YMyRYdDcQu+ry+O2zC5qxcMD5I Xy9DIL26wRG//t/D73x9y2PlbEcg5+YUxJdBBaJEpZGU5LnnMjp8KX8N3eDk9yunGlI/PWqFe6yMM NIChsERvowrn4e2EkwpJzHfAZDtD+T1F9w6cmNjVRtOUixySSYIXOtEIuozsmjKE8v9H88aLkSW7z MOYdFxoAOv923Qc8EROA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1m1Div-00Fe9o-3C; Wed, 07 Jul 2021 20:00:45 +0000 Received: from mail-ot1-x335.google.com ([2607:f8b0:4864:20::335]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1m1Diq-00Fe8U-3F for linux-arm-kernel@lists.infradead.org; Wed, 07 Jul 2021 20:00:42 +0000 Received: by mail-ot1-x335.google.com with SMTP id x22-20020a9d6d960000b0290474a76f8bd4so3461103otp.5 for ; Wed, 07 Jul 2021 13:00:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=96jWry9WOsdwKu+G0dTVRx+JdimFiJ2QAYFEbiH3H34=; b=RGANX0PGc0mFZu9cqrNOVbTfGn0v+kokDFQAPwfrxJwtPODfB/7BgVckPJVrWeW3aX Zq/e9LoJ0785EJh+wDzA6h31JQ0sQKhf5OC8+6825AOXSTrCQRvNmjr00Qv4QYBChNR1 yEToxoe8pidstwnQJpDD7tRYOzkEa8SGd8UWQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=96jWry9WOsdwKu+G0dTVRx+JdimFiJ2QAYFEbiH3H34=; b=TF3E4gERtwoXXtmsy2FZ0kFiiC4PicIcFJmE4wQa03jORGnqs/2eSzNJfJK9NkirU5 x4bvitj03p6h/erlFciF3QgrR/QYDibpczF6af6v4Z23diY1K+8GWptXPtQw5SkJkaCD dzmAxVj5jT0GtERO4gY9mPytc4GMbidZJNOxMnKVNj/fs8RXsqZSE/RpHKf6jqVT0N8X 7PxSjfH5CJFrom16manHLy872lv5ZkZ3y+JapZFZrn/ohpxVF6HU/Q7E/zqoJwFDnfeS ONxGdB4/2aY1RukqzPJfkzGv1RBXHnMrW5gy2P8Cqj/WboZLhnVySaJSzjyYiImDAKt/ bD1w== X-Gm-Message-State: AOAM532RAP6bYAQKsmJ18RMsL6gqTrH05NdO1lctLr4Hcg8sYMRgk+TP 9Cvx7ecWd9DaqmIZ8aW8eh3zLUG0f3aMvA== X-Google-Smtp-Source: ABdhPJydAgY85VvTz7uYXiTxISfHRwsUw2HFL1Qw+lDjW3oXGUqBgGPObTMGCE1ivpooGX8e55WXcQ== X-Received: by 2002:a05:6830:1e02:: with SMTP id s2mr14647688otr.37.1625688035778; Wed, 07 Jul 2021 13:00:35 -0700 (PDT) Received: from mail-ot1-f54.google.com (mail-ot1-f54.google.com. [209.85.210.54]) by smtp.gmail.com with ESMTPSA id j97sm18910otj.80.2021.07.07.13.00.35 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Jul 2021 13:00:35 -0700 (PDT) Received: by mail-ot1-f54.google.com with SMTP id 7-20020a9d0d070000b0290439abcef697so3475309oti.2 for ; Wed, 07 Jul 2021 13:00:35 -0700 (PDT) X-Received: by 2002:a25:d97:: with SMTP id 145mr35869561ybn.276.1625688024885; Wed, 07 Jul 2021 13:00:24 -0700 (PDT) MIME-Version: 1.0 References: <20210624171759.4125094-1-dianders@chromium.org> In-Reply-To: From: Doug Anderson Date: Wed, 7 Jul 2021 13:00:13 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 0/3] iommu: Enable non-strict DMA on QCom SD/MMC To: Joerg Roedel X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210707_130040_194385_B039404F X-CRM114-Status: GOOD ( 54.10 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Ulf Hansson , Linux Doc Mailing List , Peter Zijlstra , linux-pci@vger.kernel.org, Konrad Dybcio , Jordan Crouse , Thierry Reding , Joel Fernandes , Rajat Jain , Will Deacon , Rob Clark , Sai Prakash Ranjan , Saravana Kannan , Jonathan Corbet , quic_c_gdjako@quicinc.com, Linux ARM , Viresh Kumar , Veerabhadrarao Badiganti , "Paul E. McKenney" , linux-arm-msm , John Garry , Nicolin Chen , Bjorn Helgaas , Bjorn Andersson , Sonny Rao , Vlastimil Babka , Randy Dunlap , Linux MMC List , Adrian Hunter , LKML , "list@263.net:IOMMU DRIVERS , Joerg Roedel , " , Andrew Morton , Robin Murphy , "Maciej W. Rozycki" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi, On Fri, Jun 25, 2021 at 7:42 AM Doug Anderson wrote: > > Hi, > > On Fri, Jun 25, 2021 at 6:19 AM Joerg Roedel wrote: > > > > Hi Douglas, > > > > On Thu, Jun 24, 2021 at 10:17:56AM -0700, Douglas Anderson wrote: > > > The goal of this patch series is to get better SD/MMC performance on > > > Qualcomm eMMC controllers and in generally nudge us forward on the > > > path of allowing some devices to be in strict mode and others to be in > > > non-strict mode. > > > > So if I understand it right, this patch-set wants a per-device decision > > about setting dma-mode to strict vs. non-strict. > > > > I think we should get to the reason why strict mode is used by default > > first. Is the default on ARM platforms to use iommu-strict mode by > > default and if so, why? > > > > The x86 IOMMUs use non-strict mode by default (yes, it is a security > > trade-off). > > It is certainly a good question. I will say that, as per usual, I'm > fumbling around trying to solve problems in subsystems I'm not an > expert at, so if something I'm saying sounds like nonsense it probably > is. Please correct me. > > I guess I'd start out by thinking about what devices I think need to > be in "strict" mode. Most of my thoughts on this are in the 3rd patch > in the series. I think devices where it's important to be in strict > mode fall into "Case 1" from that patch description, copied here: > > Case 1: IOMMUs prevent malicious code running on the peripheral (maybe > a malicious peripheral or maybe someone exploited a benign peripheral) > from turning into an exploit of the Linux kernel. This is particularly > important if the peripheral has loadable / updatable firmware or if > the peripheral has some type of general purpose processor and is > processing untrusted inputs. It's also important if the device is > something that can be easily plugged into the host and the device has > direct DMA access itself, like a PCIe device. > > > Using sc7180 as an example (searching for iommus in sc7180.dtsi), I'd > expect these peripherals to be in strict mode: > > * WiFi / LTE - I'm almost certain we want this in "strict" mode. Both > have loadable / updatable firmware and both do complex processing on > untrusted inputs. Both have a history of being compromised over the > air just by being near an attacker. Note that on sc7180 these are > _not_ connected over PCI so we can't leverage any PCI mechanism for > deciding strict / non-strict. > > * Video decode / encode - pretty sure we want this in strict. It's got > loadable / updatable firmware and processing complex / untrusted > inputs. > > * LPASS (low power audio subsystem) - I don't know a ton and I think > we don't use this much on our designs, but I believe it meets the > definitions for needing "strict". > > * The QUPs (handles UART, SPI, and i2c) - I'm not as sure here. These > are much "smarter" than you'd expect. They have loadable / updatable > firmware and certainly have a sort of general purpose processor in > them. They also might be processing untrusted inputs, but presumably > in a pretty simple way. At the moment we don't use a ton of DMA here > anyway and these are pretty low speed, so I would tend to leave them > as strict just to be on the safe side. > > > I'd expect these to be non-strict: > > * SD/MMC - as described in this patch series. > > * USB - As far as I know firmware isn't updatable and has no history > of being compromised. > > > Special: > > * GPU - This already has a bunch of special cases, so we probably > don't need to discuss here. > > > As far as I can tell everything in sc7180.dtsi that has an "iommus" > property is classified above. So, unless I'm wrong and it's totally > fine to run LTE / WiFi / Video / LPASS in non-strict mode then: > > * We still need some way to pick strict vs. non-strict. > > * Since I've only identified two peripherals that I think should be > non-strict, having "strict" the default seems like fewer special > cases. It's also safer. > > > In terms of thinking about x86 / AMD where the default is non-strict, > I don't have any historical knowledge there. I guess the use of PCI > for connecting WiFi is more common (so you can use the PCI special > cases) and I'd sorta hope that WiFi is running in strict mode. For > video encode / decode, perhaps x86 / AMD are just accepting the risk > here because there was no kernel infrastructure for doing better? I'd > also expect that x86/AMD don't have something quite as crazy as the > QUPs for UART/I2C/SPI, but even if they do I wouldn't be terribly > upset if they were in non-strict mode. > > ...so I guess maybe the super short answer to everything above is that > I believe that at least WiFi ought to be in "strict" mode and it's not > on PCI so we need to come up with some type of per-device solution. I guess this thread has been silent for a bit of time now. Given that my previous version generated a whole bunch of traffic, I guess I'm assuming this: a) Nothing is inherently broken with my current approach. b) My current approach doesn't make anybody terribly upset even if nobody is totally in love with it. c) Nobody has any other bright ideas for ways to solve this that would make my patch series obsolete. I guess I'll take that as a good sign and hope that it means that this approach has a path forward. I suppose it could just be that everyone is busy and/or on vacation, but I've always been an optimist! My plan continues to be to send a v3 of my patch series atop Sai's patch [1] and John's series [2]. I'll plan to wait a bit longer before posting my v3 to allow for more feedback/thoughts and also to see if either Sai's patches or John's patches land and/or have newer versions posted. :-) -Doug [1] https://lore.kernel.org/r/20210623134201.16140-1-saiprakash.ranjan@codeaurora.org [2] https://lore.kernel.org/linux-doc/1624016058-189713-1-git-send-email-john.garry@huawei.com _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel