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