linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/3] Add support for privileged mappings
Date: Thu, 7 Jul 2016 18:00:26 +0100	[thread overview]
Message-ID: <20160707170026.GG20682@arm.com> (raw)
In-Reply-To: <20160706235136.27854-1-mitchelh@codeaurora.org>

On Wed, Jul 06, 2016 at 04:51:33PM -0700, Mitchel Humpherys wrote:
> The following patch to the ARM SMMU driver:
> 
>     commit d346180e70b91b3d5a1ae7e5603e65593d4622bc
>     Author: Robin Murphy <robin.murphy@arm.com>
>     Date:   Tue Jan 26 18:06:34 2016 +0000
>     
>         iommu/arm-smmu: Treat all device transactions as unprivileged
> 
> started forcing all SMMU transactions to come through as "unprivileged".
> The rationale given was that:
> 
>   (1) There is no way in the IOMMU API to even request privileged mappings.
> 
>   (2) It's difficult to implement a DMA mapper that correctly models the
>       ARM VMSAv8 behavior of unprivileged-writeable =>
>       privileged-execute-never.
> 
> This series attempts to rectify (1) by introducing an IOMMU API for
> privileged mappings (and implementing it in io-pgtable-arm).  It seems like
> (2) can be safely ignored for now under the assumption that any users of
> the IOMMU_PRIV flag will be using the low-level IOMMU APIs directly, rather
> than going through the DMA APIs.
> 
> Robin, Will, what do you think?  Jordan and Jeremy can provide more info on
> the use case if needed, but the high level is that it's a security feature
> to prevent attacks such as [1].

So I think the problem that the offending patch tried to fix is that
the PL330 DMA controller (drivers/dma/pl330.c) uses dma_alloc_coherent
to allocate its microcode buffer, but the so-called "manager" thread
that fetches the microcode does so with privileged accesses and
consequently fails.

Whilst this series is a step in the right direction for fixing that, I
don't think you can claim that only low-level users need this, given that
we have in-tree code which would break without it. Perhaps you just need
to extend things slightly more to expose this to the DMA API as well (or,
alternatively, hack the PL330 driver some how).

Will

  parent reply	other threads:[~2016-07-07 17:00 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-06 23:51 [PATCH 0/3] Add support for privileged mappings Mitchel Humpherys
2016-07-06 23:51 ` [PATCH 1/3] iommu: add IOMMU_PRIV attribute Mitchel Humpherys
2016-07-06 23:51 ` [PATCH 2/3] iommu/io-pgtable-arm: add support for the IOMMU_PRIV flag Mitchel Humpherys
2016-07-06 23:51 ` [PATCH 3/3] Revert "iommu/arm-smmu: Treat all device transactions as unprivileged" Mitchel Humpherys
2016-07-07 17:00 ` Will Deacon [this message]
2016-07-07 20:58   ` [PATCH 0/3] Add support for privileged mappings Jordan Crouse
2016-07-09  2:09     ` Mitchel Humpherys

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160707170026.GG20682@arm.com \
    --to=will.deacon@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).