lkml.org 
[lkml]   [2004]   [Jun]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: A question about PROT_NONE on ARM and ARM26
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.

> > 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.

The optimisation is valid on all architectures, actually, including
current ARM where it saves a few instructions in the common path.

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

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.

ldr r1, [r1, #TI_ADDR_LIMIT]
sub r1, r1, #4
cmp r0, r1
4: ldrlst r1, [r0]

Thanks,
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:04    [W:0.538 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site