From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] ARM: shmobile: ipmmu: Add basic PMB support
Date: Wed, 23 Jan 2013 00:04:55 +0000 [thread overview]
Message-ID: <1906988.fAZIpjYMPs@avalon> (raw)
In-Reply-To: <50FDFA17.5050107@igel.co.jp>
Hi Damian,
On Tuesday 22 January 2013 11:31:51 Damian Hobson-Garcia wrote:
> On 2013/01/21 22:12, Laurent Pinchart wrote:
> > On Friday 18 January 2013 15:35:10 Damian Hobson-Garcia wrote:
> >> The PMB can be used to remap 16, 64, 128 or 512 MiB pages from
> >> the 0x80000000-0xffffffff address range to anywhere in the
> >> 0x00000000-0x7fffffff range.
> >
> > Isn't it 0x80000000 - 0xbfffffff to 0x00000000 - 0xffffffff ?
>
> Yes, looking again at the spec, your values are the correct ones.
>
> >> It also has the ability to perform tiled-linear address translation,
> >> which can be used to access a memory buffer as a series of n x m tiles,
> >> useful for image encoding/decoding.
> >> Currently only the userspace API via character device is supported.
> >
> > If I understand this correctly, you're allowing userspace to remap a
> > virtual address block to a physical address block without performing any
> > sanity check. Isn't that a major security issue ?
>
> No, not really. The PMB will only remap physical addresses, not virtual
> addresses. Moreover, the remapped address is only accessible from the
> IP blocks which are on the ICB bus, not the CPU. I will update the
> comment to mention this. These IP blocks already have access to the
> entire physical memory address space, so I don't think that adding the
> the PMB into mix introduces any new security issues.
The IP block will be programmed through a driver that will control where it
writes to/reads from. Adding the PMB will remap those read/write operations
without notifying the driver, opening the door to potential issues.
What are the use cases for controlling the PMB from userspace ?
> ...
>
> >> +
> >> +#define PMB_DEVICE_NAME "pmb"
> >> +
> >> +#define PMB_NR 16
> >> +/* the smallest size that can be reserverd in the pmb */
> >> +#define PMB_GRANULARITY (16 << 20)
> >> +#define PMB_START_ADDR 0x80000000
> >> +#define PMB_SIZE 0x40000000
> >> +#define NUM_BITS(x) ((x) / PMB_GRANULARITY)
> >> +#define NR_BITMAPS ((NUM_BITS(PMB_SIZE) + BITS_PER_LONG - 1) \
> >> + >> ilog2(BITS_PER_LONG))
> >
> > Does ilog2(BITS_PER_LONG) resolve to a compile-time constant ?
>
> Yes it does.
>
> Thanks for your other comments too. I'll look into making those changes.
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2013-01-23 0:04 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-18 6:35 [PATCH] ARM: shmobile: ipmmu: Add basic PMB support Damian Hobson-Garcia
2013-01-21 13:12 ` Laurent Pinchart
2013-01-22 2:31 ` Damian Hobson-Garcia
2013-01-23 0:04 ` Laurent Pinchart [this message]
2013-01-24 9:42 ` Damian Hobson-Garcia
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=1906988.fAZIpjYMPs@avalon \
--to=laurent.pinchart@ideasonboard.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).