[PATCH] 2.6 PPC64: Reduce rtas spamming

[Paul Mackerras]

Dave Hansen writes:

> On Thu, 2004-07-22 at 12:12, Paul Mackerras wrote:
> > First, we won't remove any /proc files from 2.6 that are being used by
> > applications.  That's a job for 2.7.  (I think we could remove things
> > like /proc/ppc64/rtas/poweron though.)
>
> What about the new kernel development model? ;)

What about it?  I'm just saying that we're not going to remove an
existing interface that usermode is using in the 2.6 series kernels.

> The argument against /dev/mem is pretty simple: it's a bit too big of a
> hammer.  Using it will force you to either run as root, or allow a
> non-root user/group to write to it, which is an equivalent of giving
> them root.

We only want root to be able to do RTAS calls.  If you can do RTAS
calls you can do things like reboot or power off the system,
enable/disable interrupts, access PCI config space, stop the CPU, or
update flash ROM or nvram.  I'm pretty sure you could persuade RTAS to
write to arbitrary physical addresses below 4GB too.

> A suggestion would be to use the current ppc_rtas to get that
> information back out.  Could there be some special args passed to the
> syscall that give you the address of the buffer?
>
> Something conceptually along the lines of:
>
>         if (uargs->token == SPECIAL_TOKEN) {
>         	uargs->rets = phys_to_virt(&rtas_rmo_buf);
>         	return foo;
>         }

Yes, that's not a bad idea iff we can find a token value that firmware
is guaranteed not to use.  I don't see anything in the RPA that says
that token values are restricted to any particular range though.  We
could use some other invalid input such as a NULL argument buffer
pointer perhaps instead.

Paul.

** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/