[PATCH RFC 0/2] powerpc/pseries: new character devices for RTAS functions

[Michal Suchánek]

Hello,

On Tue, Aug 22, 2023 at 04:33:38PM -0500, Nathan Lynch via B4 Relay wrote:
> This is a proposal for adding chardev-based access to a select subset
> of RTAS functions on the pseries platform.
> 
> The problem: important platform features are enabled on Linux VMs
> through the powerpc-specific rtas() syscall in combination with
> writeable mappings of /dev/mem. In typical usage, this is encapsulated
> behind APIs provided by the librtas library. This paradigm is
> incompatible with lockdown, which prohibits /dev/mem access.
> 
> The solution I'm working on is to add a small pseries-specific
> "driver" for each functional area, exposing the relevant features to
> user space in ways that are compatible with lockdown. In most of these
> areas, I believe it's possible to change librtas to prefer the new
> chardev interfaces without disrupting existing users.

thanks for the driver.

> 
> I've broken down the affected functions into the following areas and
> priorities:
> 
> High priority:
> * VPD retrieval.
> * System parameters: retrieval and update.
> 
> Medium priority:
> * Platform dump retrieval.
> * Light path diagnostics (get/set-dynamic-indicator,
>   get-dynamic-sensor-state, get-indices).
> 
> Low priority (may never happen):
> * Error injection: would have to be carefully restricted.
> * Physical attestation: no known users.
> * LPAR perftools: no known users.
> 
> Out of scope:
> * DLPAR (configure-connector et al): involves device tree updates
>   which must be handled entirely in-kernel for lockdown. This is the
>   object of a separate effort.
> 
> See https://github.com/ibm-power-utilities/librtas/issues/29 for more
> details.
> 
> In this RFC, I've included a single driver for VPD retrieval. Clients
> use ioctl() to obtain a file descriptor-based handle for the VPD they
> want. I think this could be a good model for the other areas too, but
> I'd like to get opinions on it.

The call has parameters so it cannot be reasonably done with sysfs or
similar.

The paramater is string which is unweildy with ioctl, and netlink has
helpers for getting strings into and out of messages without garbage
pointers nad crashes. However, netlink does not have permissions, and
setting permissions for the different platform features available
through rtas is desirable.

Then this is as good as it gets with the kernel facilities Linux
provides.

Thanks

Michal