public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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