From: Jamie Lokier <jamie@shareable.org>
To: 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 20:14:28 +0100 [thread overview]
Message-ID: <20040630191428.GC31064@mail.shareable.org> (raw)
In-Reply-To: <20040630192654.B21104@flint.arm.linux.org.uk>
Russell King wrote:
> We use three domains - one for user, one for kernel and one for IO.
> Normally all three are in client mode. However, on set_fs(KERNEL_DS)
> we switch the kernel domain to manager mode.
>
> This means that the user-mode LDR instructions (ldrt / ldrlst etc)
> will not have their page permissions checked, and therefore the access
> will succeed - exactly as we require.
Protection permissions (i.e. read-only, PROT_NONE) should still be
checked after set_fs(KERNEL_DS). It's only the kernel page vs. user
page distinction that should be relaxed.
>From your description, it's not obvious that it'll do the right thing
in that circumstance.
Hopefully,
> [Tables]
> We have a similar difference in kernel-mode vs user-mode accesses for
> the ARM case as well - so its all complicated and unless you really
> understand this... 8)
...this is alluding to a mechanism such that exactly the right thing
happens for PROT_NONE and PROT_READONLY pages after set_fs(KERNEL_DS), yes?
> Privileged T-bit 00 01 10 11
> Y 0 r/w r/w r/w r/w
> Y 1 r/w read no access no access
> N X r/w read no access no access
>
> Note: if PAGE_NOT_USER and PAGE_OLD are both clear (iow, young + user
> page) we use bit pattern 0x. If PAGE_NOT_USER, PAGE_OLD, PAGE_READONLY
> and PAGE_CLEAN are all clear, we use bit pattern 00. Otherwise we use
> bit pattern 11.
Ok, that explains nicely and should do the right thing on ARM26 with
PROT_NONE pages, even with set_fs(KERNEL_DS).
Because set_fs() is rarely used, I think you can optimise getuser.S
and putuser.S on ARM26. Instead of comparing the address against
TI_ADDR_LIMIT, compare it against the hard-coded userspace limit.
If that succeeds, continue with ldrt et al. Note the improvements in
the common case (fs == USER_DS and no fault): (1) you only compare
against one limit, not two; (2) no load of TI_ADDR_LIMIT; (3) one less
ldr instruction.
If that comparison fails, then branch to a version which checks
TI_ADDR_LIMIT.
Here's an example. It's probably wrong as I haven't written ARM in a
long time, but illustrates the idea. Note how the common case takes 4
instructions instead of 12 in the current code:
__get_user_4:
cmp r0,#0x02000000
4: ldrlst r1, [r0]
movls r0, #0
movls pc, lr
bic r1, sp, #0x1f00
bic r1, r1, #0x00ff
str lr, [sp, #-4]!
ldr r1, [r1, #TI_ADDR_LIMIT]
sub r1, r1, #4
cmp r0, r1
14: ldrls r1, [r0]
movls r0, #0
ldmfdls sp!, {pc}^
b __get_user_bad
-- Jamie
next prev parent reply other threads:[~2004-06-30 19:14 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 [this message]
2004-06-30 19:23 ` Russell King
2004-06-30 20:15 ` Jamie Lokier
2004-06-30 22:59 ` Russell King
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=20040630191428.GC31064@mail.shareable.org \
--to=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