linux-kernel - Re: [Uclinux-dist-devel] [PATCH v2] NOMMU: add support for Memory Protection Units (MPU)

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: <8bd0f97a0907150552rb69b953t85e73d14a995efb3@mail.gmail.com>
Date:	Wed, 15 Jul 2009 08:52:23 -0400
From:	Mike Frysinger <vapier.adi@...il.com>
To:	David Howells <dhowells@...hat.com>
Cc:	Bernd Schmidt <bernds_cb1@...nline.de>,
	uclinux-dist-devel@...ckfin.uclinux.org,
	linux-kernel@...r.kernel.org
Subject: Re: [Uclinux-dist-devel] [PATCH v2] NOMMU: add support for Memory 
	Protection Units (MPU)

On Wed, Jul 15, 2009 at 08:25, David Howells wrote:
> Mike Frysinger wrote:
>> yes, you can see page_rwx_mask in our mmu.h's mm_context_t.  this is
>> what the protect_page/update_protections operate on.  we have a global
>> current_rwx_mask that gets updated during context changes and the CPLB
>> miss handler uses that to keep things simple.
>
> Interesting.
>
> Since FRV does not really allow separate execute permissions (it has a very
> few separate static I and D protection/mapping registers and a shared TLB), I
> could do it with just pairs of bits.
>
> Also, how do you deal with mappable devices that lie outside of RAM?  I'm
> guessing from the code that you don't cover those with the bitmap, but rather
> just grant userspace RW access.

yes, there are really only three such regions on Blackfin systems:
 - on-chip rom
 - async memory banks
 - on-chip sram

since the first is read-only, letting random things execute/read there
isnt going to cause a problem.  any supervisor-only
accesses/instructions would be caught anyways if userspace attempted
it.

the second could (should?) be restricted like normal (granting access
via ioremap/mmap), but right now we just grant full access to
everyone.  the banks are largely used for drivers only
(usb/eth/flash/fpga/etc...), so having protection for that region
doesnt gain us too much.  perhaps down the line we'll look into it.

the on-chip srams are so small that 4k (or even 1k -- the smallest
page we can handle) would waste most resources.  so we either lock a
CPLB entry for full access (L1), or always grant it (L2).  and again,
experience has shown that it is largely used by drivers only, so
protection here wouldnt gain much as there is so rarely bad behavior
going on.
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/