On Thu, Sep 07, 2023 at 11:52:44AM -0500, Nathan Lynch wrote: > Michal Suchánek <msucha...@suse.de> writes: > > On Wed, Sep 06, 2023 at 02:34:59PM -0500, Nathan Lynch wrote: > >> Michal Suchanek <msucha...@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.
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. Additional discussion here https://github.com/linuxppc/issues/issues/252 > > 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. Thanks Michal
