[Cbe-oss-dev] [RFC] Reading Local Store base address from SPU using stop-and-signal with kernel support

[Arnd Bergmann]

On Wednesday 30 May 2007, Patrick Mansfield wrote:

> Is the EA of the LS (as seen by the kernel) for a given SPU context
> dynamic? If a context is not running it looks like the EA (result of the
> ->get_ls() call) can change.
> 
> So the SPU can't have a static LS EA that can be used inside the kernel?
> 
> And so we can't use raw SPU syscalls (in the kernel, like via
> spu_callbacks.c) that point to anywhere in LS? Like for open(path, flag)
> on the SPU path would normally just be an LS address, but we need to add
> some constant (over the life of the SPU context) LS EA base address so
> the kernel can reference it.

You are mixing up several points here, let me try to explain:

The virtual address of the local store in kernel can be either the result
of the ioremap operation for a given physical SPU, which is constant for
that SPU, or the backing store for a context, which is allocated using
vmalloc when the context is created.

If you want to access the LS of a context inside of the kernel, you can
only do it using spu_acquire(ctx); ctx->ops->get_ls(ctx); spu_release(ctx);.
Outside of the acquire/release, the pointer can change as the result of
scheduling to/from a real SPU, but not when you have acquired the context.

In theory, you could do the system call inside of the acquire, and
guarantee a constant mapping of the LS, but that would have a number
of serious problems:

* Syscalls expect addresses to be user virtual, not kernel virtual in the
first place, i.e. with the top address bits all zero. Passing kernel
addresses to copy_from_user/copy_to_user results in -EFAULT being returned
from practically all syscalls.

* You can circumvent that using the get_fs()/set_fs() logic, but that's
dangerous, as you can't do real range checking, e.g. some ioctl commands
pass pointers to structures with more pointers, so a malicious SPU
program could easily access kernel data structures this way

* Scheduling is disabled on a context when you call spu_acquire(), so
e.g. by calling nanosleep() with a long timeout, a malicious application
can keep an SPU by being used by anyone else.

	Arnd <><