On 4/8/06, Matt Thomas <matt@3am-software.com> wrote:
>
> On Apr 7, 2006, at 11:44 PM, Rahul Kulkarni wrote:
>
> > 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)
>
> The above is only true for the OEA PPCs.  Each processor/architecture
> does something different but appropriate for themselves.
>
> > 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..
>
> Of course.  The kernel can do anything.  It's part of the TCB.
>
> > 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. ?
>
> No.  User code does not run in kernel context.  Only the kernel does.
> The portion of kernel that is performing actions for the user code
> of process won't randomly trample parts of the user's address space.
>

RK->>>>>>>I did not mean user code in the kernel context..Let me
rephrase that  If a buggy system call or a buggy ioctl servicing a
user process happens to potentially trample parts of the user adress
space will it generate a DSI or an exception? since the USERSR is
invalid at that point? Is there any other window in the kernel other
than copy{in,out} where USERSR is valid?


> Note that USERSR is only valid when the kernel is doing a copy{in,out}.
> Also when the kernel returns to user processing, *all* SRs are replaced
> with the user's SRs (including USERSR).  When the user process traps to
> the kernel, USERSR is initialized to an inactive SR.
>
> > Are you suggesting by controlling the USERSR in copyin/copy out the
> > access to user space can be controlled in the kernel ?
>
> of course.
>
> > 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?
>
> See above. USERSR is only set to a valid value for small windows
> in the kernel.
>
> > Also any specifics why all the physical memory for powerpc's is BAT
> > mapped?
>
> Because it allows easy and efficient access to physical memory.  It
> also limits
> the amount of virtual memory needed by the kernel.
>
>
>