From: Russell King <rmk+lkml@arm.linux.org.uk>
To: Jamie Lokier <jamie@shareable.org>
Cc: Ian Molton <spyro@f2s.com>,
linux-arm-kernel@lists.arm.linux.org.uk,
linux-kernel@vger.kernel.org
Subject: Re: A question about PROT_NONE on ARM and ARM26
Date: Wed, 30 Jun 2004 23:59:22 +0100 [thread overview]
Message-ID: <20040630235921.C1496@flint.arm.linux.org.uk> (raw)
In-Reply-To: <20040630201546.GD31064@mail.shareable.org>; from jamie@shareable.org on Wed, Jun 30, 2004 at 09:15:46PM +0100
On Wed, Jun 30, 2004 at 09:15:46PM +0100, Jamie Lokier wrote:
> Russell King wrote:
> > Trust me, it does. Unless you fully understand how the MMU and domains
> > work on ARM, you've little chance of working it out from the code.
>
> Thanks, that's fine. I just wanted you to confirm PROT_NONE works
> with set_fs(KERNEL_DS), as it's not apparent from your earlier
> description. I don't need to know _how_ it works - I can read manuals
> too - although you description was interesting.
Ok, to fill in for just this bit, the domain covering user space mappings
always remains in "client" mode, so page protections are always checked.
PAGE_NONE does not have the "user" bit set, so both user space accesses
and ldrt/strt instructions will be unable to access the pages, which is
the desired behaviour.
However, plain ldr and str instructions will access the page, but
get_user/put_user doesn't use them, and copy_from_user/copy_to_user
are carefully crafted to ensure that we hit the necessary permission
checks for each page it touches on the first access.
> > > Instead of comparing the address against TI_ADDR_LIMIT, compare it
> > > against the hard-coded userspace limit.
> >
> > Wrong. That means that if userspace passes an address above the hard
> > coded limit, we _WILL_ bypass all protections and access that memory.
>
> No - it does check against TI_ADDR_LIMIT in the case that the address
> is above the hard-coded limit, so prevents that.
Ok.
> Here's the potential improvement to current 32-bit ARM. It's
> 4 instructions instead of 8 and one less load, in the common case:
>
> __get_user_4:
> cmp r0, #TASK_SIZE-4
> 4: ldrlet r1, [r0]
> movle r0, #0
> movle pc, lr
> bic r1, sp, #0x1f00
> bic r1, r1, #0x00ff
> ldr r1, [r1, #TI_ADDR_LIMIT]
> sub r1, r1, #4
> cmp r0, r1
> 14: ldrlet r1, [r0]
> movle r0, #0
> movle pc, lr
> b __get_user_bad
Ok, this could work, but there's one gotcha - TASK_SIZE-4 doesn't fit
in an 8-bit rotated constants, so we need 2 extra instructions:
__get_user_4:
mov r1, #TASK_SIZE
sub r1, r1, #4
cmp r0, r1
4: ldrlet r1, [r0]
movle r0, #0
movle pc, lr
...
> Finally, I think I see a bug in current ARM. Shouldn't this use
> ldrlet instead of ldrlst? Think about accesses to addresses
> TASK_SIZE-4 and 0xfffffffc.
LS = unsigned less than or same. LE = signed less than or equal. You
need the unsigned compare because addresses are unsigned.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
next prev parent reply other threads:[~2004-06-30 22:59 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-30 2:44 A question about PROT_NONE on ARM and ARM26 Jamie Lokier
2004-06-30 3:38 ` William Lee Irwin III
2004-07-01 3:26 ` Testing PROT_NONE and other protections, and a surprise Jamie Lokier
2004-07-01 3:35 ` William Lee Irwin III
2004-07-01 4:01 ` Jamie Lokier
2004-07-01 3:44 ` Kyle Moffett
2004-07-01 4:11 ` Jamie Lokier
2004-07-01 4:59 ` Kyle Moffett
2004-07-01 12:39 ` Jamie Lokier
2004-07-01 14:43 ` [OT] " Kyle Moffett
2004-07-01 14:50 ` Jamie Lokier
2004-07-01 15:01 ` Kyle Moffett
2004-07-01 16:37 ` Matt Mackall
2004-07-01 17:26 ` Michael Driscoll
2004-07-02 7:37 ` Gabriel Paubert
2004-07-01 12:52 ` Russell King
2004-07-01 14:26 ` Richard Curnow
2004-06-30 8:16 ` A question about PROT_NONE on ARM and ARM26 Russell King
2004-06-30 14:59 ` Jamie Lokier
2004-06-30 15:22 ` Ian Molton
2004-06-30 18:26 ` Russell King
2004-06-30 19:14 ` Jamie Lokier
2004-06-30 19:23 ` Russell King
2004-06-30 20:15 ` Jamie Lokier
2004-06-30 22:59 ` Russell King [this message]
2004-06-30 23:30 ` Jamie Lokier
2004-06-30 23:48 ` Ian Molton
2004-07-01 1:59 ` Jamie Lokier
2004-07-01 1:05 ` Nicolas Pitre
2004-07-01 1:50 ` Jamie Lokier
2004-07-02 18:39 ` Russell King
2004-07-01 15:27 ` Scott Wood
2004-07-01 23:53 ` Jamie Lokier
2004-07-02 14:36 ` Scott Wood
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=20040630235921.C1496@flint.arm.linux.org.uk \
--to=rmk+lkml@arm.linux.org.uk \
--cc=jamie@shareable.org \
--cc=linux-arm-kernel@lists.arm.linux.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=spyro@f2s.com \
/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