| Message ID | 20230822-papr-sys_rtas-vs-lockdown-v1-0-932623cf3c7b@linux.ibm.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | powerpc/pseries: new character devices for RTAS functions | expand |
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
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. 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. In the next iteration I expect to add a separate driver for system parameters. For reference, I floated a different approach for system parameters here: https://lore.kernel.org/linuxppc-dev/20220730000458.130938-1-nathanl@linux.ibm.com/ --- Nathan Lynch (2): powerpc/pseries: papr-vpd char driver for VPD retrieval powerpc/selftests: add test for papr-vpd Documentation/userspace-api/ioctl/ioctl-number.rst | 2 + arch/powerpc/include/uapi/asm/papr-vpd.h | 29 ++ arch/powerpc/platforms/pseries/Makefile | 1 + arch/powerpc/platforms/pseries/papr-vpd.c | 353 +++++++++++++++++++++ tools/testing/selftests/powerpc/Makefile | 1 + .../testing/selftests/powerpc/papr_vpd/.gitignore | 1 + tools/testing/selftests/powerpc/papr_vpd/Makefile | 12 + .../testing/selftests/powerpc/papr_vpd/papr_vpd.c | 351 ++++++++++++++++++++ 8 files changed, 750 insertions(+) --- base-commit: d77497508a229529830850ba07e1e52596463d21 change-id: 20230817-papr-sys_rtas-vs-lockdown-5c54505db792 Best regards,