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