Thanks Matt. appreciate your reply. If you can elaborate a bit more it
would help

I am running 1.6.1 on a powerpc 750..Haven't mucked around with the
BAT stuff, and the USERSR. But it does appear like you pointed out
that all of the physical memory is BAT mapped and the copyin/copy out
leaves the user segment mapped in the USERSR. (Is this what you refer
to as implementation? or is there something else)

I am concluding the above based on some experiments, From the kernel
ddb i am able to look at the executable segment of a known userland
process and comparing and verifying it with the object dump of  the
executable which does indicate visibility and access..

A few more followup questions if you may:

Though the kernel and user address spaces are completely disjoint,
given the above facts couldn't a process running in the kernel /
kernel itself trample and mess with the user space. ?

Are you suggesting by controlling the USERSR in copyin/copy out the
access to user space can be controlled in the kernel ?

Is it default behaviour to leave the user segment mapped into the
kernel's USERSR? Is it due to performace or what is the prime purpose?

Also any specifics why all the physical memory for powerpc's is BAT mapped?


thanks much in advance for your reply.



On 4/7/06, Matt Thomas <matt@3am-software.com> wrote:
>
> On Apr 7, 2006, at 10:08 PM, Rahul Kulkarni wrote:
>
> > A fundamental question:
> >
> > Does the kernel have write acess to user land address space and can it
> > corrupt user land addresses (process user text/stack/data)?
>
> It depends on the implementation
>
> > Is the total physical memory BAT mapped in the kernel or is it the
> > first 256MB?.
>
> On powerpc, all of physical memory is BAT mapped.  However that isn't a
> problem since the kernel and user addres spaces are completely disjoint.
>
> > How can this behaviour be controlled in the UVM/BAT registers i.e to
> > provide process user address space protection in the kernel ?
>
> This is controlled by copyin/copyout and the use of USERSR.
>
> --
> Matt Thomas                     email: matt@3am-software.com
> 3am Software Foundry              www: http://3am-software.com/bio/matt/
> Cupertino, CA              disclaimer: I avow all knowledge of this
> message.
>
>
>
>