On Tue, Sep 05, 2023 at 12:42:11PM +1000, Michael Ellerman wrote: > Michal Suchánek <msucha...@suse.de> writes: > > On Thu, Aug 31, 2023 at 12:59:25PM -0500, Nathan Lynch wrote: > ... > >> You (Michal) seem to favor a kernel-user ABI where user space is allowed > >> to invoke arbitrary RTAS functions by name. But we already have that in > >> the form of the rtas() syscall. (User space looks up function tokens by > >> name in the DT.) The point of the series is that we need to move away > >> from that. It's too low-level and user space has to use /dev/mem when > >> invoking any of the less-simple RTAS functions. > > > > We don't have that, directly accessing /dev/mem does not really work. > > And that's what needs fixing in my view. > > > > The rtas calls are all mechanically the same, the function implemented > > here should be able to call any of them if there was a way to specify > > the call. > > > > Given that there is desire to have access to multiple calls I don't > > think it makes sense to allocate a separate device with different name > > for each. > > I think it does make sense. > > We explicitly don't want a general "call any RTAS function" API. > > We want tightly scoped APIs that do one thing, or a family of related > things, but not anything & everything. > > Having different devices for each of those APIs means permissions can be > granted separately on those devices. So a user/group can be given access > to the "papr-vpd" device, but not some other unrelated device that also > happens to expose an RTAS service (eg. error injection).
Yes, it does work as a kludge for setting permissions for individual calls. Thanks Michal