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

[Nathan Lynch]

>> > 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.
>
> I am referring to this list of known uses:
>
> https://github.com/ibm-power-utilities/librtas/issues/29
>
> rtas_get_vpd is used by lsvpd (through libvpd and librtas)
> rtas_platform_dump and rtas_get_indices is used by ppc64-diag
> rtas_cfg_connector is used by powerpc-utils and is planned to be
> replaced by in-kernel solution
>
> That covers the complex cases.
>
> rtas_set_sysparm is used by ppc64-diag and powerpc-utils
> rtas_set_dynamic_indicator, rtas_get_dynamic_sensor are used by
> ppc64-diag (related to rtas_get_indices)
> rtas_errinjct + open/close are used by powerpc-utils
>
> That's the simple cases.

None of these would work "either way" with lockdown. They all use work
area buffer arguments and must move away from sys_rtas and /dev/mem. The
librtas issue you refer to makes that clear.


>> > 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?
>
> Either the goal is to completely remove sys_rtas, and then an option for
> disabling it is helpful for uncovering unexpected problems. Or thre
> isn't a goal of sys_rtas removal, and then there is no point in having
> an option to disable it, and it can be used for calls that don't need
> buffers indefinitely.

I don't agree that those are the only two options, but removal of
sys_rtas is not going to be a goal of this series. The goal is to
provide alternative ABIs that are compatible with lockdown.