transition away from /dev/mem

[nathanlynch]

All librtas APIs that require passing a "work area" to the underlying RTAS calls use /dev/mem to allocate buffers that are addressable by RTAS. When the kernel lockdown feature is enabled, this becomes impossible, and different kernel-user APIs are necessary.

This issue is for cataloging the affected APIs and the proposed solutions. Many can be fixed by adding new (likely ioctl-oriented) interfaces to the kernel and supporting code within librtas without requiring changes to librtas clients. Some, like rtas_cfg_connector, are fundamentally incompatible with lockdown and modern Linux device configuration architecture, and its users need to be migrated to solutions outside of librtas.

librtas function	proposed solution	known users	use case	RTAS function style
rtas_cfg_connector	Deprecate. Users should transition to device configuration APIs outside of librtas. Needs kernel and powerpc-utils changes.	drmgr (powerpc-utils)	I/O DLPAR	streaming
rtas_display_msg	Deprecate. Unspecified in PAPR 2.12. Not present on 950 or 860 FW.	none	none	simple
rtas_errinjct	ioctl or debugfs. Likely needs to be disabled under lockdown regardless of kernel-user interface. Lockdown on x86 prohibits ACPI error injection.	errinjct (powerpc-utils)	error injection, e.g. during device driver development	simple
rtas_errinjct_open	see rtas_errinjct			simple
rtas_errinjct_close	see rtas_errinjct			simple
rtas_free_rmo_buffer	see rtas_get_rmo_buffer	none	none	n/a
rtas_get_dynamic_sensor	ioctl	lpd (ppc64-diag)	light path diagnostics	simple
rtas_get_indices	ioctl	lpd (ppc64-diag)	light path diagnostics	streaming
rtas_get_rmo_buffer	Deprecate. Cannot work with lockdown. Existing librtas users do not need this to use any other librtas APIs. Only conceivable use case is a client which also uses the rtas syscall directly instead of librtas APIs.	none	none	n/a
rtas_get_sysparm	ioctl	rtas_errd (ppc64-diag), activate_fw, ppc64_cpu, serv_config, sys_ident (powerpc-utils), lscpu (util-linux), RSCT	HMC communication, various others	simple
rtas_get_vpd	ioctl? Complex to support existing callers. Note that PAPR requires ibm,get-vpd call sequences to be serialized, so existing uses are fragile already.	vpdupdate (lsvpd)	RAS, inventory, ?	streaming
rtas_lpar_perftools	ioctl? perf?	none	unknown	streaming
rtas_platform_dump	ioctl	rtas_errd (ppc64-diag)	RAS, diagnostics	streaming
rtas_physical_attestation	ioctl	IBM TPM Attestation Client Server (sample/reference code, likely few if any "real" users)	trusted boot / remote attestation	streaming
rtas_scan_log_dump	Deprecate. Likely old CHRP facility, not present on PAPR systems.	none	none	simple
rtas_set_dynamic_indicator	ioctl	lpd (ppc64-diag)	light path diagnostics	simple
rtas_set_sysparm	ioctl	rtas_errd (ppc64-diag), activate_fw, ppc64_cpu, serv_config (powerpc-utils)	LPAR reboot policy, etc	simple
rtas_update_nodes	Deprecate. LPM and PRRN device tree updates are kernel responsibilities.	dead code in drmgr (powerpc-utils)	none	streaming
rtas_update_properties	Deprecate. See rtas_update_nodes.			streaming

[nathanlynch]

Many of the calls in this table are straightforward to convert to an ioctl-based interface: it is more or less obvious how to structure a command, call the ioctl, and process the result. Examples: rtas_get_sysparm, rtas_display_msg, rtas_set_sysparm.

It seems more complex to support rtas_get_vpd, rtas_platform_dump, and rtas_lpar_perftools. These are "sequence-based" calls, in which the caller typically invokes the function multiple times in order to complete the higher-level operation, retrieving the results from the work area 4KB at a time. The difficulties with these are:

• PAPR prohibits beginning a new sequence for a given call while one is outstanding, e.g. beginning a rtas_get_vpd sequence while one is already in progress will disrupt the first sequence.
• These sequences can return relatively "large" amounts of data in total, exceeding the size of the structure that can be passed via ioctl directly (~8KB). I think VPD or platform dumps are likely to be largest in practice, perhaps a few MB at most? (guessing)
• The low-level sequence-based nature of these RTAS functions is exposed to librtas callers. E.g. existing users of rtas_get_vpd are coded to invoke the function in a loop until all VPD has been retrieved.

Every API in the table above is either "simple" or "sequence-based", with the possible exception of the error injection APIs, which may be in their own category.

[nathanlynch]

Added columns for higher level use case as well as RTAS function category as discussed in earlier comment. "simple" means one-shot, "streaming" covers the sequence-based pattern I described.