[PATCH RFC] powerpc/rtas: Make it possible to disable sys_rtas

Michal Suchánek msuchanek at suse.de
Fri Sep 8 02:01:34 AEST 2023

On Wed, Sep 06, 2023 at 02:34:59PM -0500, Nathan Lynch wrote:
> Michal Suchanek <msuchanek at suse.de> writes:
> > Additional patch suggestion to go with the rtas devices:
> >
> > -----------------------------------------------------------------------
> >
> > With most important rtas functions available through different
> > interfaces the sys_rtas interface can be disabled completely.
> >
> > Do not remove it for now to make it possible to run older versions of
> > userspace tools that don't support other interfaces.
> Thanks. I hope making sys_rtas on/off-configurable will make sense
> eventually, and I expect this series to get us closer to that. But to me
> it seems too early and too coarse. A kernel built with RTAS_SYSCALL=n is
> not something I'd want to support or run in production soon. It would
> break too many known use cases, and likely some unknown ones as well.

There are about 3 known use cases that absolutely need access by other
means than sys_rtas to work with lockdown, and about other 3 that would
work either way.

That's not so staggering that it could not be implemented in the kernel
from the start.
How long it will take for the known userspace users to catch up is
anotehr questio but again it's something that can be addressed.

Making it possible to turn off sys_rtas will make it easier to uncover
the not yet known cases.

What people want to support depends a lot on what is converted, and also
the situation of the distribution in question. Fast-rollong
distributions may want only the new interface quite soon, and so may
distributions that are starting development of new release.

All this makes sense only if there is a plan to discontinue sys_rtas
entirely. For the simple calls that don't need data buffers it's still

> It could be more useful in the near term to construct a configurable
> list of RTAS functions that sys_rtas is allowed to expose.

If we really need this level of datail I guess it is too early.



More information about the Linuxppc-dev mailing list