lkml.org 
[lkml]   [2003]   [May]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] i386 uaccess to fixmap pages

On Fri, 9 May 2003, Jamie Lokier wrote:
>
> Why don't you change TASK_SIZE to 0xc0001000 (or so) and place the
> user-visible fixmaps at 0xc0000000?

I think I almost agree..

> That would have no cost at all.

It actually does have some cost in that form, namely the fact that the
kernel 1:1 mapping needs to be 4MB-aligned in order to take advantage of
large-pte support. So we'd have to move the kernel to something like
0xc0400000 (and preferably higher, to make sure there is a nice hole in
between - say 0xc1000000), which in turn has a cost of verifying that
nothing assumes the current lay-out (we've had the 1/2/3GB TASK_SIZE
patches floating around, but they've never had "odd sizes").

There's another cost, which is that right now we share the pgd with the
kernel fixmaps, and this would mean that we'd have a new one. That's just
a single page, though.

But it might "just work", and it would be interesting to see what the
patch would look like. Hint hint.

[ The current "TASK_SIZE comes up to start of kernel" is actually a bad
design, since it makes the boundary between user mapping a kernel
mapping a very abrupt one without any hole in between - opening us up
for problems with overflows from user space addresses to kernel
addresses on x86.

In particular, if we use the wrong size to "access_ok()", a user program
could fool the kernel to access low kernel memory. I don't know of any
such bug, but having to be careful about it _did_ complicate
"strcpy_from_user()" on x86. So from a security angle it would also be
good to do this ]

Linus

-
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 13:35    [W:0.070 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site