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

[Nathan Lynch]

Michal Suchánek <msuchanek at suse.de> writes:
> 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.

How do you figure that? I count 11 librtas APIs that use work areas (and
therefore /dev/mem) that are definitely broken under lockdown. Maybe a
couple of them are unused.

> 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.

This is also true of making the configuration more granular than on or
off. You would be free to disallow all calls if desired.

> 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
> usable.

I don't understand. How would it remain usable for the simple calls if
it can be completely disabled?

>> 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.

I'm not sure we do, like I said it's just an idea at this point.