linux-kernel - [PATCH V9 7/9] dmaengine: pl330: Make sure microcode is privileged

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1483709296-32761-8-git-send-email-sricharan@codeaurora.org>
Date:   Fri,  6 Jan 2017 18:58:14 +0530
From:   Sricharan R <sricharan@...eaurora.org>
To:     jcrouse@...eaurora.org, pdaly@...eaurora.org,
        jgebben@...eaurora.org, joro@...tes.org,
        linux-kernel@...r.kernel.org, pratikp@...eaurora.org,
        iommu@...ts.linux-foundation.org, robin.murphy@....com,
        tzeng@...eaurora.org, linux-arm-kernel@...ts.infradead.org,
        will.deacon@....com, mitchelh@...eaurora.org, vinod.koul@...el.com,
        dan.j.williams@...el.com, linux@...linux.org.uk
Cc:     sricharan@...eaurora.org
Subject: [PATCH V9 7/9] dmaengine: pl330: Make sure microcode is privileged

From: Mitchel Humpherys <mitchelh@...eaurora.org>

The PL330 is hard-wired such that instruction fetches on both the
manager and channel threads go out onto the bus with the "privileged"
bit set. This can become troublesome once there is an IOMMU or other
form of memory protection downstream, since those will typically be
programmed by the DMA mapping subsystem in the expectation of normal
unprivileged transactions (such as the PL330 channel threads' own data
accesses as currently configured by this driver).

To avoid the case of, say, an IOMMU blocking an unexpected privileged
transaction with a permission fault, use the newly-introduced
DMA_ATTR_PRIVILEGED attribute for the mapping of our microcode buffer.
That way the DMA layer can do whatever it needs to do to make things
continue to work as expected on more complex systems.

Cc: Dan Williams <dan.j.williams@...el.com>
Cc: Vinod Koul <vinod.koul@...el.com>
Reviewed-by: Robin Murphy <robin.murphy@....com>
Tested-by: Robin Murphy <robin.murphy@....com>
Acked-by: Will Deacon <will.deacon@....com>
Acked-by: Vinod Koul <vinod.koul@...el.com>
Signed-off-by: Mitchel Humpherys <mitchelh@...eaurora.org>
[rm: remove now-redundant local variable, clarify commit message]
Signed-off-by: Robin Murphy <robin.murphy@....com>
---
 drivers/dma/pl330.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 87fd015..5a90d0c 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -1864,9 +1864,10 @@ static int dmac_alloc_resources(struct pl330_dmac *pl330)
 	 * Alloc MicroCode buffer for 'chans' Channel threads.
 	 * A channel's buffer offset is (Channel_Id * MCODE_BUFF_PERCHAN)
 	 */
-	pl330->mcode_cpu = dma_alloc_coherent(pl330->ddma.dev,
+	pl330->mcode_cpu = dma_alloc_attrs(pl330->ddma.dev,
 				chans * pl330->mcbufsz,
-				&pl330->mcode_bus, GFP_KERNEL);
+				&pl330->mcode_bus, GFP_KERNEL,
+				DMA_ATTR_PRIVILEGED);
 	if (!pl330->mcode_cpu) {
 		dev_err(pl330->ddma.dev, "%s:%d Can't allocate memory!\n",
 			__func__, __LINE__);
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation