prefer /dev/papr-vpd and /dev/papr-sysparm when available #36
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
nathanlynch
added a commit
to nathanlynch/linuxppc-ci
that referenced
this pull request
Oct 7, 2023
Add character devices that expose PAPR-specific system parameters and VPD to user space. 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. It also is too low-level in many cases: a single logical operation may require multiple sys_rtas() calls in succession to complete. This carries the risk that a process may exit while leaving an operation unfinished. It also means that callers must coordinate their use of the syscall for functions that cannot tolerate multiple concurrent clients, such as ibm,get-vpd. The solution presented here is to add a pair of small pseries-specific "drivers," one for VPD and one for system parameters. The new drivers expose these facilities to user space in ways that are compatible with lockdown and require no coordination between their clients. Both drivers could potentially support poll() methods to notify clients of changes to parameters or VPD that happen due to partition migration and other events. But that should be safe to leave for later, assuming there's any interest. I have made changes to librtas to prefer the new interfaces and verified that existing clients work correctly with the new code. A draft PR for that work is here: ibm-power-utilities/librtas#36 I expect to propose at least one more small driver in this style for platform dump retrieval in a separate submission in the future. I consider the work in this series mature enough now to request review for inclusion as-is. To: Michael Ellerman <[email protected]> To: Nicholas Piggin <[email protected]> To: Michal Suchánek <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] --- Changes in v2: - EDITME: describe what is new in this series revision. - EDITME: use bulletpoints and terse descriptions. - Link to v1: https://lore.kernel.org/r/20231006-papr-sys_rtas-vs-lockdown-v1-0-3a36bfb66e2e@linux.ibm.com Changes in v1 vs initial RFC: - Add papr-sysparm driver and tests. - Add a papr-miscdev.h uapi header. - Prevent sys_rtas() from interfering with papr-vpd call sequences. - Handle -4 ("VPD changed") status in papr-vpd. - Include string_helpers.h in papr-vpd.c, per Michal Suchánek - Link to RFC: https://lore.kernel.org/r/20230822-papr-sys_rtas-vs-lockdown-v1-0-932623cf3c7b@linux.ibm.com --- b4-submit-tracking --- # This section is used internally by b4 prep for tracking purposes. { "series": { "revision": 2, "change-id": "20230817-papr-sys_rtas-vs-lockdown-5c54505db792", "prefixes": [], "history": { "v1": [ "20230822-papr-sys_rtas-vs-lockdown-v1-0-932623cf3c7b@linux.ibm.com", "20231006-papr-sys_rtas-vs-lockdown-v1-0-3a36bfb66e2e@linux.ibm.com" ] } } }
nathanlynch
added a commit
to nathanlynch/linux
that referenced
this pull request
Oct 13, 2023
Add character devices that expose PAPR-specific system parameters and VPD to user space. 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. It also is too low-level in many cases: a single logical operation may require multiple sys_rtas() calls in succession to complete. This carries the risk that a process may exit while leaving an operation unfinished. It also means that callers must coordinate their use of the syscall for functions that cannot tolerate multiple concurrent clients, such as ibm,get-vpd. The solution presented here is to add a pair of small pseries-specific "drivers," one for VPD and one for system parameters. The new drivers expose these facilities to user space in ways that are compatible with lockdown and require no coordination between their clients. Both drivers could potentially support poll() methods to notify clients of changes to parameters or VPD that happen due to partition migration and other events. But that should be safe to leave for later, assuming there's any interest. I have made changes to librtas to prefer the new interfaces and verified that existing clients work correctly with the new code. A draft PR for that work is here: ibm-power-utilities/librtas#36 I expect to propose at least one more small driver in this style for platform dump retrieval in a separate submission in the future. To: Michael Ellerman <[email protected]> To: Nicholas Piggin <[email protected]> To: Michal Suchánek <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] --- Changes in v2: - Fix unused-but-set variable warning in papr-sysparm code. - Rebase on powerpc/next branch. - Link to v1: https://lore.kernel.org/r/20231006-papr-sys_rtas-vs-lockdown-v1-0-3a36bfb66e2e@linux.ibm.com Changes in v1 vs initial RFC: - Add papr-sysparm driver and tests. - Add a papr-miscdev.h uapi header. - Prevent sys_rtas() from interfering with papr-vpd call sequences. - Handle -4 ("VPD changed") status in papr-vpd. - Include string_helpers.h in papr-vpd.c, per Michal Suchánek - Link to RFC: https://lore.kernel.org/r/20230822-papr-sys_rtas-vs-lockdown-v1-0-932623cf3c7b@linux.ibm.com --- b4-submit-tracking --- { "series": { "revision": 2, "change-id": "20230817-papr-sys_rtas-vs-lockdown-5c54505db792", "prefixes": [], "history": { "v1": [ "20230822-papr-sys_rtas-vs-lockdown-v1-0-932623cf3c7b@linux.ibm.com", "20231006-papr-sys_rtas-vs-lockdown-v1-0-3a36bfb66e2e@linux.ibm.com" ] } } }
nathanlynch
added a commit
to nathanlynch/linux
that referenced
this pull request
Oct 26, 2023
Add character devices that expose PAPR-specific system parameters and VPD to user space. 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. It also is too low-level in many cases: a single logical operation may require multiple sys_rtas() calls in succession to complete. This carries the risk that a process may exit while leaving an operation unfinished. It also means that callers must coordinate their use of the syscall for functions that cannot tolerate multiple concurrent clients, such as ibm,get-vpd. The solution presented here is to add a pair of small pseries-specific "drivers," one for VPD and one for system parameters. The new drivers expose these facilities to user space in ways that are compatible with lockdown and require no coordination between their clients. Since the ibm,get-vpd call sequence performed by the papr-vpd driver must be serialized against all other uses of the function, the series begins by adding some new APIs to the core RTAS support code for this purpose. Both drivers could potentially support poll() methods to notify clients of changes to parameters or VPD that happen due to partition migration and other events. But that should be safe to leave for later, assuming there's any interest. I have made changes to librtas to prefer the new interfaces and verified that existing clients work correctly with the new code. A draft PR for that work is here: ibm-power-utilities/librtas#36 The user-space ABI has not changed since v1 of this series. I expect to propose at least one more small driver in this style for platform dump retrieval in a separate submission in the future. To: Michael Ellerman <[email protected]> To: Nicholas Piggin <[email protected]> To: Michal Suchánek <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] --- Changes in v3: - Add new rtas_function_lock()/unlock() APIs and convert existing code to use them. - Convert papr-vpd to use rtas_function_lock()/unlock() instead of having sys_rtas() obtain a driver-private mutex. - Rebase on current powerpc/next. - Link to v2: https://lore.kernel.org/r/20231013-papr-sys_rtas-vs-lockdown-v2-0-ead01ce01722@linux.ibm.com Changes in v2: - Fix unused-but-set variable warning in papr-sysparm code. - Rebase on powerpc/next branch. - Link to v1: https://lore.kernel.org/r/20231006-papr-sys_rtas-vs-lockdown-v1-0-3a36bfb66e2e@linux.ibm.com Changes in v1 vs initial RFC: - Add papr-sysparm driver and tests. - Add a papr-miscdev.h uapi header. - Prevent sys_rtas() from interfering with papr-vpd call sequences. - Handle -4 ("VPD changed") status in papr-vpd. - Include string_helpers.h in papr-vpd.c, per Michal Suchánek - Link to RFC: https://lore.kernel.org/r/20230822-papr-sys_rtas-vs-lockdown-v1-0-932623cf3c7b@linux.ibm.com --- b4-submit-tracking --- { "series": { "revision": 3, "change-id": "20230817-papr-sys_rtas-vs-lockdown-5c54505db792", "prefixes": [], "history": { "v1": [ "20230822-papr-sys_rtas-vs-lockdown-v1-0-932623cf3c7b@linux.ibm.com", "20231006-papr-sys_rtas-vs-lockdown-v1-0-3a36bfb66e2e@linux.ibm.com" ], "v2": [ "20231013-papr-sys_rtas-vs-lockdown-v2-0-ead01ce01722@linux.ibm.com" ] } } }
nathanlynch
added a commit
to nathanlynch/linux
that referenced
this pull request
Oct 26, 2023
Add character devices that expose PAPR-specific system parameters and VPD to user space. 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. It also is too low-level in many cases: a single logical operation may require multiple sys_rtas() calls in succession to complete. This carries the risk that a process may exit while leaving an operation unfinished. It also means that callers must coordinate their use of the syscall for functions that cannot tolerate multiple concurrent clients, such as ibm,get-vpd. The solution presented here is to add a pair of small pseries-specific "drivers," one for VPD and one for system parameters. The new drivers expose these facilities to user space in ways that are compatible with lockdown and require no coordination between their clients. Since the ibm,get-vpd call sequence performed by the papr-vpd driver must be serialized against all other uses of the function, the series begins by adding some new APIs to the core RTAS support code for this purpose. Both drivers could potentially support poll() methods to notify clients of changes to parameters or VPD that happen due to partition migration and other events. But that should be safe to leave for later, assuming there's any interest. I have made changes to librtas to prefer the new interfaces and verified that existing clients work correctly with the new code. A draft PR for that work is here: ibm-power-utilities/librtas#36 The user-space ABI has not changed since v1 of this series. I expect to propose at least one more small driver in this style for platform dump retrieval in a separate submission in the future. To: Michael Ellerman <[email protected]> To: Nicholas Piggin <[email protected]> To: Michal Suchánek <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] --- Changes in v3: - Add new rtas_function_lock()/unlock() APIs and convert existing code to use them. - Convert papr-vpd to use rtas_function_lock()/unlock() instead of having sys_rtas() obtain a driver-private mutex. - Rebase on current powerpc/next. - Link to v2: https://lore.kernel.org/r/20231013-papr-sys_rtas-vs-lockdown-v2-0-ead01ce01722@linux.ibm.com Changes in v2: - Fix unused-but-set variable warning in papr-sysparm code. - Rebase on powerpc/next branch. - Link to v1: https://lore.kernel.org/r/20231006-papr-sys_rtas-vs-lockdown-v1-0-3a36bfb66e2e@linux.ibm.com Changes in v1 vs initial RFC: - Add papr-sysparm driver and tests. - Add a papr-miscdev.h uapi header. - Prevent sys_rtas() from interfering with papr-vpd call sequences. - Handle -4 ("VPD changed") status in papr-vpd. - Include string_helpers.h in papr-vpd.c, per Michal Suchánek - Link to RFC: https://lore.kernel.org/r/20230822-papr-sys_rtas-vs-lockdown-v1-0-932623cf3c7b@linux.ibm.com --- b4-submit-tracking --- { "series": { "revision": 3, "change-id": "20230817-papr-sys_rtas-vs-lockdown-5c54505db792", "prefixes": [], "history": { "v1": [ "20230822-papr-sys_rtas-vs-lockdown-v1-0-932623cf3c7b@linux.ibm.com", "20231006-papr-sys_rtas-vs-lockdown-v1-0-3a36bfb66e2e@linux.ibm.com" ], "v2": [ "20231013-papr-sys_rtas-vs-lockdown-v2-0-ead01ce01722@linux.ibm.com" ] } } }
nathanlynch
added a commit
to nathanlynch/linux
that referenced
this pull request
Oct 26, 2023
Add character devices that expose PAPR-specific system parameters and VPD to user space. 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. It also is too low-level in many cases: a single logical operation may require multiple sys_rtas() calls in succession to complete. This carries the risk that a process may exit while leaving an operation unfinished. It also means that callers must coordinate their use of the syscall for functions that cannot tolerate multiple concurrent clients, such as ibm,get-vpd. The solution presented here is to add a pair of small pseries-specific "drivers," one for VPD and one for system parameters. The new drivers expose these facilities to user space in ways that are compatible with lockdown and require no coordination between their clients. Since the ibm,get-vpd call sequence performed by the papr-vpd driver must be serialized against all other uses of the function, the series begins by adding some new APIs to the core RTAS support code for this purpose. Both drivers could potentially support poll() methods to notify clients of changes to parameters or VPD that happen due to partition migration and other events. But that should be safe to leave for later, assuming there's any interest. I have made changes to librtas to prefer the new interfaces and verified that existing clients work correctly with the new code. A draft PR for that work is here: ibm-power-utilities/librtas#36 The user-space ABI has not changed since v1 of this series. I expect to propose at least one more small driver in this style for platform dump retrieval in a separate submission in the future. To: Michael Ellerman <[email protected]> To: Nicholas Piggin <[email protected]> Cc: [email protected] Cc: Michal Suchánek <[email protected]> Cc: [email protected] Cc: [email protected] --- Changes in v3: - Add new rtas_function_lock()/unlock() APIs and convert existing code to use them. - Convert papr-vpd to use rtas_function_lock()/unlock() instead of having sys_rtas() obtain a driver-private mutex. - Rebase on current powerpc/next. - Link to v2: https://lore.kernel.org/r/20231013-papr-sys_rtas-vs-lockdown-v2-0-ead01ce01722@linux.ibm.com Changes in v2: - Fix unused-but-set variable warning in papr-sysparm code. - Rebase on powerpc/next branch. - Link to v1: https://lore.kernel.org/r/20231006-papr-sys_rtas-vs-lockdown-v1-0-3a36bfb66e2e@linux.ibm.com Changes in v1 vs initial RFC: - Add papr-sysparm driver and tests. - Add a papr-miscdev.h uapi header. - Prevent sys_rtas() from interfering with papr-vpd call sequences. - Handle -4 ("VPD changed") status in papr-vpd. - Include string_helpers.h in papr-vpd.c, per Michal Suchánek - Link to RFC: https://lore.kernel.org/r/20230822-papr-sys_rtas-vs-lockdown-v1-0-932623cf3c7b@linux.ibm.com --- b4-submit-tracking --- { "series": { "revision": 3, "change-id": "20230817-papr-sys_rtas-vs-lockdown-5c54505db792", "prefixes": [], "history": { "v1": [ "20230822-papr-sys_rtas-vs-lockdown-v1-0-932623cf3c7b@linux.ibm.com", "20231006-papr-sys_rtas-vs-lockdown-v1-0-3a36bfb66e2e@linux.ibm.com" ], "v2": [ "20231013-papr-sys_rtas-vs-lockdown-v2-0-ead01ce01722@linux.ibm.com" ] } } }
|
Link to v3 kernel submission https://lore.kernel.org/linuxppc-dev/20231025-papr-sys_rtas-vs-lockdown-v3-0-5eb04559e7d8@linux.ibm.com/ |
nathanlynch
added a commit
to nathanlynch/linux
that referenced
this pull request
Oct 26, 2023
Add character devices that expose PAPR-specific system parameters and VPD to user space. 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. It also is too low-level in many cases: a single logical operation may require multiple sys_rtas() calls in succession to complete. This carries the risk that a process may exit while leaving an operation unfinished. It also means that callers must coordinate their use of the syscall for functions that cannot tolerate multiple concurrent clients, such as ibm,get-vpd. The solution presented here is to add a pair of small pseries-specific "drivers," one for VPD and one for system parameters. The new drivers expose these facilities to user space in ways that are compatible with lockdown and require no coordination between their clients. Since the ibm,get-vpd call sequence performed by the papr-vpd driver must be serialized against all other uses of the function, the series begins by adding some new APIs to the core RTAS support code for this purpose. Both drivers could potentially support poll() methods to notify clients of changes to parameters or VPD that happen due to partition migration and other events. But that should be safe to leave for later, assuming there's any interest. I have made changes to librtas to prefer the new interfaces and verified that existing clients work correctly with the new code. A draft PR for that work is here: ibm-power-utilities/librtas#36 The user-space ABI has not changed since v1 of this series. I expect to propose at least one more small driver in this style for platform dump retrieval in a separate submission in the future. To: Michael Ellerman <[email protected]> To: Nicholas Piggin <[email protected]> Cc: [email protected] Cc: Michal Suchánek <[email protected]> Cc: [email protected] Cc: [email protected] --- Changes in v4: - EDITME: describe what is new in this series revision. - EDITME: use bulletpoints and terse descriptions. - Link to v3: https://lore.kernel.org/r/20231025-papr-sys_rtas-vs-lockdown-v3-0-5eb04559e7d8@linux.ibm.com Changes in v3: - Add new rtas_function_lock()/unlock() APIs and convert existing code to use them. - Convert papr-vpd to use rtas_function_lock()/unlock() instead of having sys_rtas() obtain a driver-private mutex. - Rebase on current powerpc/next. - Link to v2: https://lore.kernel.org/r/20231013-papr-sys_rtas-vs-lockdown-v2-0-ead01ce01722@linux.ibm.com Changes in v2: - Fix unused-but-set variable warning in papr-sysparm code. - Rebase on powerpc/next branch. - Link to v1: https://lore.kernel.org/r/20231006-papr-sys_rtas-vs-lockdown-v1-0-3a36bfb66e2e@linux.ibm.com Changes in v1 vs initial RFC: - Add papr-sysparm driver and tests. - Add a papr-miscdev.h uapi header. - Prevent sys_rtas() from interfering with papr-vpd call sequences. - Handle -4 ("VPD changed") status in papr-vpd. - Include string_helpers.h in papr-vpd.c, per Michal Suchánek - Link to RFC: https://lore.kernel.org/r/20230822-papr-sys_rtas-vs-lockdown-v1-0-932623cf3c7b@linux.ibm.com --- b4-submit-tracking --- # This section is used internally by b4 prep for tracking purposes. { "series": { "revision": 4, "change-id": "20230817-papr-sys_rtas-vs-lockdown-5c54505db792", "prefixes": [], "history": { "v1": [ "20230822-papr-sys_rtas-vs-lockdown-v1-0-932623cf3c7b@linux.ibm.com", "20231006-papr-sys_rtas-vs-lockdown-v1-0-3a36bfb66e2e@linux.ibm.com" ], "v2": [ "20231013-papr-sys_rtas-vs-lockdown-v2-0-ead01ce01722@linux.ibm.com" ], "v3": [ "20231025-papr-sys_rtas-vs-lockdown-v3-0-5eb04559e7d8@linux.ibm.com" ] } } }
nathanlynch
added a commit
to nathanlynch/linuxppc-ci
that referenced
this pull request
Oct 26, 2023
Add character devices that expose PAPR-specific system parameters and VPD to user space. 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. It also is too low-level in many cases: a single logical operation may require multiple sys_rtas() calls in succession to complete. This carries the risk that a process may exit while leaving an operation unfinished. It also means that callers must coordinate their use of the syscall for functions that cannot tolerate multiple concurrent clients, such as ibm,get-vpd. The solution presented here is to add a pair of small pseries-specific "drivers," one for VPD and one for system parameters. The new drivers expose these facilities to user space in ways that are compatible with lockdown and require no coordination between their clients. Since the ibm,get-vpd call sequence performed by the papr-vpd driver must be serialized against all other uses of the function, the series begins by adding some new APIs to the core RTAS support code for this purpose. Both drivers could potentially support poll() methods to notify clients of changes to parameters or VPD that happen due to partition migration and other events. But that should be safe to leave for later, assuming there's any interest. I have made changes to librtas to prefer the new interfaces and verified that existing clients work correctly with the new code. A draft PR for that work is here: ibm-power-utilities/librtas#36 The user-space ABI has not changed since v1 of this series. I expect to propose at least one more small driver in this style for platform dump retrieval in a separate submission in the future. To: Michael Ellerman <[email protected]> To: Nicholas Piggin <[email protected]> Cc: [email protected] Cc: Michal Suchánek <[email protected]> Cc: [email protected] Cc: [email protected] --- Changes in v4: - EDITME: describe what is new in this series revision. - EDITME: use bulletpoints and terse descriptions. - Link to v3: https://lore.kernel.org/r/20231025-papr-sys_rtas-vs-lockdown-v3-0-5eb04559e7d8@linux.ibm.com Changes in v3: - Add new rtas_function_lock()/unlock() APIs and convert existing code to use them. - Convert papr-vpd to use rtas_function_lock()/unlock() instead of having sys_rtas() obtain a driver-private mutex. - Rebase on current powerpc/next. - Link to v2: https://lore.kernel.org/r/20231013-papr-sys_rtas-vs-lockdown-v2-0-ead01ce01722@linux.ibm.com Changes in v2: - Fix unused-but-set variable warning in papr-sysparm code. - Rebase on powerpc/next branch. - Link to v1: https://lore.kernel.org/r/20231006-papr-sys_rtas-vs-lockdown-v1-0-3a36bfb66e2e@linux.ibm.com Changes in v1 vs initial RFC: - Add papr-sysparm driver and tests. - Add a papr-miscdev.h uapi header. - Prevent sys_rtas() from interfering with papr-vpd call sequences. - Handle -4 ("VPD changed") status in papr-vpd. - Include string_helpers.h in papr-vpd.c, per Michal Suchánek - Link to RFC: https://lore.kernel.org/r/20230822-papr-sys_rtas-vs-lockdown-v1-0-932623cf3c7b@linux.ibm.com --- b4-submit-tracking --- { "series": { "revision": 4, "change-id": "20230817-papr-sys_rtas-vs-lockdown-5c54505db792", "prefixes": [], "history": { "v1": [ "20230822-papr-sys_rtas-vs-lockdown-v1-0-932623cf3c7b@linux.ibm.com", "20231006-papr-sys_rtas-vs-lockdown-v1-0-3a36bfb66e2e@linux.ibm.com" ], "v2": [ "20231013-papr-sys_rtas-vs-lockdown-v2-0-ead01ce01722@linux.ibm.com" ], "v3": [ "20231025-papr-sys_rtas-vs-lockdown-v3-0-5eb04559e7d8@linux.ibm.com" ] } } }
nathanlynch
added a commit
to nathanlynch/linux
that referenced
this pull request
Nov 19, 2023
Add character devices that expose PAPR-specific system parameters and VPD to user space. 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. It also is too low-level in many cases: a single logical operation may require multiple sys_rtas() calls in succession to complete. This carries the risk that a process may exit while leaving an operation unfinished. It also means that callers must coordinate their use of the syscall for functions that cannot tolerate multiple concurrent clients, such as ibm,get-vpd. The solution presented here is to add a pair of small pseries-specific "drivers," one for VPD and one for system parameters. The new drivers expose these facilities to user space in ways that are compatible with lockdown and require no coordination between their clients. Since the ibm,get-vpd call sequence performed by the papr-vpd driver must be serialized against all other uses of the function, the series begins by adding some new APIs to the core RTAS support code for this purpose. Both drivers could potentially support poll() methods to notify clients of changes to parameters or VPD that happen due to partition migration and other events. But that should be safe to leave for later, assuming there's any interest. I have made changes to librtas to prefer the new interfaces and verified that existing clients work correctly with the new code. A draft PR for that work is here: ibm-power-utilities/librtas#36 The user-space ABI has not changed since v1 of this series. I expect to propose at least one more small driver in this style for platform dump retrieval in a separate submission in the future. To: Michael Ellerman <[email protected]> To: Nicholas Piggin <[email protected]> Cc: [email protected] Cc: Michal Suchánek <[email protected]> Cc: [email protected] Cc: [email protected] --- Changes in v5: - EDITME: describe what is new in this series revision. - EDITME: use bulletpoints and terse descriptions. - Link to v4: https://lore.kernel.org/r/20231117-papr-sys_rtas-vs-lockdown-v4-0-b794d8cb8502@linux.ibm.com Changes in v4: - Fix latent issue in rtas_token_to_function() which causes boot-time crashes. - More small preparatory changes: a function table iterator and additional symbolic constants for RTAS function return values. - Use symbolic constants for ibm,get-vpd statuses in papr-vpd.c. - Add commentary to papr_vpd_ioc_create_handle() explaining choice to retrieve all VPD at file handle creation time instead of deferring it to the read handler. - Rebase on current powerpc/next. - Link to v3: https://lore.kernel.org/r/20231025-papr-sys_rtas-vs-lockdown-v3-0-5eb04559e7d8@linux.ibm.com Changes in v3: - Add new rtas_function_lock()/unlock() APIs and convert existing code to use them. - Convert papr-vpd to use rtas_function_lock()/unlock() instead of having sys_rtas() obtain a driver-private mutex. - Rebase on current powerpc/next. - Link to v2: https://lore.kernel.org/r/20231013-papr-sys_rtas-vs-lockdown-v2-0-ead01ce01722@linux.ibm.com Changes in v2: - Fix unused-but-set variable warning in papr-sysparm code. - Rebase on powerpc/next branch. - Link to v1: https://lore.kernel.org/r/20231006-papr-sys_rtas-vs-lockdown-v1-0-3a36bfb66e2e@linux.ibm.com Changes in v1 vs initial RFC: - Add papr-sysparm driver and tests. - Add a papr-miscdev.h uapi header. - Prevent sys_rtas() from interfering with papr-vpd call sequences. - Handle -4 ("VPD changed") status in papr-vpd. - Include string_helpers.h in papr-vpd.c, per Michal Suchánek - Link to RFC: https://lore.kernel.org/r/20230822-papr-sys_rtas-vs-lockdown-v1-0-932623cf3c7b@linux.ibm.com --- b4-submit-tracking --- # This section is used internally by b4 prep for tracking purposes. { "series": { "revision": 5, "change-id": "20230817-papr-sys_rtas-vs-lockdown-5c54505db792", "prefixes": [], "history": { "v1": [ "20230822-papr-sys_rtas-vs-lockdown-v1-0-932623cf3c7b@linux.ibm.com", "20231006-papr-sys_rtas-vs-lockdown-v1-0-3a36bfb66e2e@linux.ibm.com" ], "v2": [ "20231013-papr-sys_rtas-vs-lockdown-v2-0-ead01ce01722@linux.ibm.com" ], "v3": [ "20231025-papr-sys_rtas-vs-lockdown-v3-0-5eb04559e7d8@linux.ibm.com" ], "v4": [ "20231117-papr-sys_rtas-vs-lockdown-v4-0-b794d8cb8502@linux.ibm.com" ] } } }
|
That pthread_once indeed breaks libservicelog build: |
|
nathanlynch
added a commit
to nathanlynch/linuxppc-ci
that referenced
this pull request
Dec 6, 2023
Add character devices that expose PAPR-specific system parameters and VPD to user space. 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. It also is too low-level in many cases: a single logical operation may require multiple sys_rtas() calls in succession to complete. This carries the risk that a process may exit while leaving an operation unfinished. It also means that callers must coordinate their use of the syscall for functions that cannot tolerate multiple concurrent clients, such as ibm,get-vpd. These are the general problems, but it's difficult to formulate a similarly general solution in the form of a single replacement ABI for sys_rtas(). Instead, each platform facility we expose to user space needs a specific interface that forms the kernel-user interactions at a higher level than individual RTAS calls. I've identified system parameter support as a high priority for this effort, since the software that communicates with the management console relies on it and therefore does not work at all with lockdown enabled on current kernels. VPD retrieval is also important (for licensing/entitlement things I think?), and serves as a good initial example of encapsulating sequence-based RTAS calls. So this series proposes a model for incrementally solving these issues by introducing a small pseries-specific "driver" for each of these platform functions. The new drivers expose these facilities to user space in ways that are compatible with lockdown, and they require no coordination between their clients. In preparation, per-function mutexes are added to the core RTAS code to serialize access to sequence-based RTAS functions. These prevent kernel-based sequences from interfering with each other, and they prevent sys_rtas() users from disrupting kernel-based users. The RTAS core enforces correct lock usage when lockdep is enabled. Both drivers could potentially support poll() methods to notify clients of changes to parameters or VPD that happen due to partition migration and other events. But that should be safe to leave for later, assuming there's any interest. I have made changes to librtas to prefer the new interfaces and verified that existing clients work correctly with the new code. A draft PR for that work is here: ibm-power-utilities/librtas#36 The user-space ABI has not changed since v1 of this series. I expect to propose at least one more small driver in this style for platform dump retrieval in a separate submission in the future. Other facilities may follow as needs are identified. To: Michael Ellerman <[email protected]> To: Nicholas Piggin <[email protected]> Cc: [email protected] Cc: Michal Suchánek <[email protected]> Cc: [email protected] Cc: [email protected] --- Changes in v5: - Add another latent bug fix to prevent spurious warning stack traces in sys_rtas(). - Fix spurious testcase failure in environments without a working ibm,set-system-parameter RTAS function. (Michael Ellerman) - Merge "powerpc/uapi: Export papr-miscdev.h header" into "Add papr-vpd character driver for VPD retrieval" so we don't temporarily expose the PAPR_MISCDEV_IOC_ID constant via UAPI without also updating the ioctl-number documentation. (Michael Ellerman) - Assert that rtas_ibm_get_vpd_lock is held in rtas_ibm_get_vpd(). - Add missing include directives to papr-vpd and papr-sysparm. (Michal Suchánek) - Drop rtas_function_{un}lock() in favor of more explicit use of the new per-function mutexes; make rtas_ibm_get_vpd_lock extern. - TODO below: - Add example lock usage to "powerpc/rtas: Facilitate high-level call sequences" - Include document version when citing the PAPR+ specification throughout. (Michael Ellerman) - Link to v4: https://lore.kernel.org/r/20231117-papr-sys_rtas-vs-lockdown-v4-0-b794d8cb8502@linux.ibm.com Changes in v4: - Fix latent issue in rtas_token_to_function() which causes boot-time crashes. - More small preparatory changes: a function table iterator and additional symbolic constants for RTAS function return values. - Use symbolic constants for ibm,get-vpd statuses in papr-vpd.c. - Add commentary to papr_vpd_ioc_create_handle() explaining choice to retrieve all VPD at file handle creation time instead of deferring it to the read handler. - Rebase on current powerpc/next. - Link to v3: https://lore.kernel.org/r/20231025-papr-sys_rtas-vs-lockdown-v3-0-5eb04559e7d8@linux.ibm.com Changes in v3: - Add new rtas_function_lock()/unlock() APIs and convert existing code to use them. - Convert papr-vpd to use rtas_function_lock()/unlock() instead of having sys_rtas() obtain a driver-private mutex. - Rebase on current powerpc/next. - Link to v2: https://lore.kernel.org/r/20231013-papr-sys_rtas-vs-lockdown-v2-0-ead01ce01722@linux.ibm.com Changes in v2: - Fix unused-but-set variable warning in papr-sysparm code. - Rebase on powerpc/next branch. - Link to v1: https://lore.kernel.org/r/20231006-papr-sys_rtas-vs-lockdown-v1-0-3a36bfb66e2e@linux.ibm.com Changes in v1 vs initial RFC: - Add papr-sysparm driver and tests. - Add a papr-miscdev.h uapi header. - Prevent sys_rtas() from interfering with papr-vpd call sequences. - Handle -4 ("VPD changed") status in papr-vpd. - Include string_helpers.h in papr-vpd.c, per Michal Suchánek - Link to RFC: https://lore.kernel.org/r/20230822-papr-sys_rtas-vs-lockdown-v1-0-932623cf3c7b@linux.ibm.com --- b4-submit-tracking --- { "series": { "revision": 5, "change-id": "20230817-papr-sys_rtas-vs-lockdown-5c54505db792", "prefixes": [], "history": { "v1": [ "20230822-papr-sys_rtas-vs-lockdown-v1-0-932623cf3c7b@linux.ibm.com", "20231006-papr-sys_rtas-vs-lockdown-v1-0-3a36bfb66e2e@linux.ibm.com" ], "v2": [ "20231013-papr-sys_rtas-vs-lockdown-v2-0-ead01ce01722@linux.ibm.com" ], "v3": [ "20231025-papr-sys_rtas-vs-lockdown-v3-0-5eb04559e7d8@linux.ibm.com" ], "v4": [ "20231117-papr-sys_rtas-vs-lockdown-v4-0-b794d8cb8502@linux.ibm.com" ] } } }
nathanlynch
added a commit
to nathanlynch/linux
that referenced
this pull request
Dec 7, 2023
Add character devices that expose PAPR-specific system parameters and VPD to user space. 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. It also is too low-level in many cases: a single logical operation may require multiple sys_rtas() calls in succession to complete. This carries the risk that a process may exit while leaving an operation unfinished. It also means that callers must coordinate their use of the syscall for functions that cannot tolerate multiple concurrent clients, such as ibm,get-vpd. These are the general problems, but it's difficult to formulate a similarly general solution in the form of a single replacement ABI for sys_rtas(). Instead, each platform facility we expose to user space needs a specific interface that forms the kernel-user interactions at a higher level than individual RTAS calls. I've identified system parameter support as a high priority for this effort, since the software that communicates with the management console relies on it and therefore does not work at all with lockdown enabled on current kernels. VPD retrieval is also important (for licensing/entitlement things I think?), and serves as a good initial example of encapsulating sequence-based RTAS calls. So this series proposes a model for incrementally solving these issues by introducing a small pseries-specific "driver" for each of these platform functions. The new drivers expose these facilities to user space in ways that are compatible with lockdown, and they require no coordination between their clients. In preparation, per-function mutexes are added to the core RTAS code to serialize access to sequence-based RTAS functions. These prevent kernel-based sequences from interfering with each other, and they prevent sys_rtas() users from disrupting kernel-based users. The RTAS core enforces correct lock usage when lockdep is enabled. Both drivers could potentially support poll() methods to notify clients of changes to parameters or VPD that happen due to partition migration and other events. But that should be safe to leave for later, assuming there's any interest. I have made changes to librtas to prefer the new interfaces and verified that existing clients work correctly with the new code. A draft PR for that work is here: ibm-power-utilities/librtas#36 The user-space ABI has not changed since v1 of this series. I expect to propose at least one more small driver in this style for platform dump retrieval in a separate submission in the future. Other facilities may follow as needs are identified. To: Michael Ellerman <[email protected]> To: Nicholas Piggin <[email protected]> Cc: [email protected] Cc: Michal Suchánek <[email protected]> Cc: [email protected] Cc: [email protected] --- Changes in v5: - Add to the front of the queue another fix for a latent bug where sys_rtas() users can trigger a spurious warning backtrace. - Merge "powerpc/uapi: Export papr-miscdev.h header" into "Add papr-vpd character driver for VPD retrieval" so we don't temporarily expose the PAPR_MISCDEV_IOC_ID constant via UAPI without also updating the ioctl-number documentation. (Michael Ellerman) - Drop rtas_function_{un}lock() in favor of more explicit use of the new per-function mutexes; make rtas_ibm_get_vpd_lock extern for use by papr-vpd. - Assert that rtas_ibm_get_vpd_lock is held in rtas_ibm_get_vpd(). - Drop the now-unnecessary 04/13 "powerpc/rtas: Factor out function descriptor lookup". - Include document version when citing the PAPR+ specification throughout. (Michael Ellerman) - Add missing include directives to papr-vpd and papr-sysparm. (Michal Suchánek) - Fix spurious testcase failure in environments without a working ibm,set-system-parameter RTAS function. (Michael Ellerman) - Link to v4: https://lore.kernel.org/r/20231117-papr-sys_rtas-vs-lockdown-v4-0-b794d8cb8502@linux.ibm.com Changes in v4: - Fix latent issue in rtas_token_to_function() which causes boot-time crashes. - More small preparatory changes: a function table iterator and additional symbolic constants for RTAS function return values. - Use symbolic constants for ibm,get-vpd statuses in papr-vpd.c. - Add commentary to papr_vpd_ioc_create_handle() explaining choice to retrieve all VPD at file handle creation time instead of deferring it to the read handler. - Rebase on current powerpc/next. - Link to v3: https://lore.kernel.org/r/20231025-papr-sys_rtas-vs-lockdown-v3-0-5eb04559e7d8@linux.ibm.com Changes in v3: - Add new rtas_function_lock()/unlock() APIs and convert existing code to use them. - Convert papr-vpd to use rtas_function_lock()/unlock() instead of having sys_rtas() obtain a driver-private mutex. - Rebase on current powerpc/next. - Link to v2: https://lore.kernel.org/r/20231013-papr-sys_rtas-vs-lockdown-v2-0-ead01ce01722@linux.ibm.com Changes in v2: - Fix unused-but-set variable warning in papr-sysparm code. - Rebase on powerpc/next branch. - Link to v1: https://lore.kernel.org/r/20231006-papr-sys_rtas-vs-lockdown-v1-0-3a36bfb66e2e@linux.ibm.com Changes in v1 vs initial RFC: - Add papr-sysparm driver and tests. - Add a papr-miscdev.h uapi header. - Prevent sys_rtas() from interfering with papr-vpd call sequences. - Handle -4 ("VPD changed") status in papr-vpd. - Include string_helpers.h in papr-vpd.c, per Michal Suchánek - Link to RFC: https://lore.kernel.org/r/20230822-papr-sys_rtas-vs-lockdown-v1-0-932623cf3c7b@linux.ibm.com --- b4-submit-tracking --- { "series": { "revision": 5, "change-id": "20230817-papr-sys_rtas-vs-lockdown-5c54505db792", "prefixes": [], "history": { "v1": [ "20230822-papr-sys_rtas-vs-lockdown-v1-0-932623cf3c7b@linux.ibm.com", "20231006-papr-sys_rtas-vs-lockdown-v1-0-3a36bfb66e2e@linux.ibm.com" ], "v2": [ "20231013-papr-sys_rtas-vs-lockdown-v2-0-ead01ce01722@linux.ibm.com" ], "v3": [ "20231025-papr-sys_rtas-vs-lockdown-v3-0-5eb04559e7d8@linux.ibm.com" ], "v4": [ "20231117-papr-sys_rtas-vs-lockdown-v4-0-b794d8cb8502@linux.ibm.com" ] } } }
nathanlynch
added a commit
to nathanlynch/linux
that referenced
this pull request
Dec 7, 2023
Add character devices that expose PAPR-specific system parameters and VPD to user space. 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. It also is too low-level in many cases: a single logical operation may require multiple sys_rtas() calls in succession to complete. This carries the risk that a process may exit while leaving an operation unfinished. It also means that callers must coordinate their use of the syscall for functions that cannot tolerate multiple concurrent clients, such as ibm,get-vpd. These are the general problems, but it's difficult to formulate a similarly general solution in the form of a single replacement ABI for sys_rtas(). Instead, each platform facility we expose to user space needs a specific interface that forms the kernel-user interactions at a higher level than individual RTAS calls. I've identified system parameter support as a high priority for this effort, since the software that communicates with the management console relies on it and therefore does not work at all with lockdown enabled on current kernels. VPD retrieval is also important (for licensing/entitlement things I think?), and serves as a good initial example of encapsulating sequence-based RTAS calls. So this series proposes a model for incrementally solving these issues by introducing a small pseries-specific "driver" for each of these platform functions. The new drivers expose these facilities to user space in ways that are compatible with lockdown, and they require no coordination between their clients. In preparation, per-function mutexes are added to the core RTAS code to serialize access to sequence-based RTAS functions. These prevent kernel-based sequences from interfering with each other, and they prevent sys_rtas() users from disrupting kernel-based users. The RTAS core enforces correct lock usage when lockdep is enabled. Both drivers could potentially support poll() methods to notify clients of changes to parameters or VPD that happen due to partition migration and other events. But that should be safe to leave for later, assuming there's any interest. I have made changes to librtas to prefer the new interfaces and verified that existing clients work correctly with the new code. A draft PR for that work is here: ibm-power-utilities/librtas#36 The user-space ABI has not changed since v1 of this series. I expect to propose at least one more small driver in this style for platform dump retrieval in a separate submission in the future. Other facilities may follow as needs are identified. To: Michael Ellerman <[email protected]> To: Nicholas Piggin <[email protected]> Cc: [email protected] Cc: Michal Suchánek <[email protected]> Cc: [email protected] Cc: [email protected] --- Changes in v5: - Add to the front of the queue another fix for a latent bug where sys_rtas() users can trigger a spurious warning backtrace. - Merge "powerpc/uapi: Export papr-miscdev.h header" into "Add papr-vpd character driver for VPD retrieval" so we don't temporarily expose the PAPR_MISCDEV_IOC_ID constant via UAPI without also updating the ioctl-number documentation. (Michael Ellerman) - Drop rtas_function_{un}lock() in favor of more explicit use of the new per-function mutexes; make rtas_ibm_get_vpd_lock extern for use by papr-vpd. - Assert that rtas_ibm_get_vpd_lock is held in rtas_ibm_get_vpd(). - Add example usage to "powerpc/rtas: Facilitate high-level call sequences". (Aneesh Kumar K.V) - Drop the now-unnecessary 04/13 "powerpc/rtas: Factor out function descriptor lookup". - Include document version when citing the PAPR+ specification throughout. (Michael Ellerman) - Add missing include directives to papr-vpd and papr-sysparm. (Michal Suchánek) - Fix spurious testcase failure in environments without a working ibm,set-system-parameter RTAS function. (Michael Ellerman) - Link to v4: https://lore.kernel.org/r/20231117-papr-sys_rtas-vs-lockdown-v4-0-b794d8cb8502@linux.ibm.com Changes in v4: - Fix latent issue in rtas_token_to_function() which causes boot-time crashes. - More small preparatory changes: a function table iterator and additional symbolic constants for RTAS function return values. - Use symbolic constants for ibm,get-vpd statuses in papr-vpd.c. - Add commentary to papr_vpd_ioc_create_handle() explaining choice to retrieve all VPD at file handle creation time instead of deferring it to the read handler. - Rebase on current powerpc/next. - Link to v3: https://lore.kernel.org/r/20231025-papr-sys_rtas-vs-lockdown-v3-0-5eb04559e7d8@linux.ibm.com Changes in v3: - Add new rtas_function_lock()/unlock() APIs and convert existing code to use them. - Convert papr-vpd to use rtas_function_lock()/unlock() instead of having sys_rtas() obtain a driver-private mutex. - Rebase on current powerpc/next. - Link to v2: https://lore.kernel.org/r/20231013-papr-sys_rtas-vs-lockdown-v2-0-ead01ce01722@linux.ibm.com Changes in v2: - Fix unused-but-set variable warning in papr-sysparm code. - Rebase on powerpc/next branch. - Link to v1: https://lore.kernel.org/r/20231006-papr-sys_rtas-vs-lockdown-v1-0-3a36bfb66e2e@linux.ibm.com Changes in v1 vs initial RFC: - Add papr-sysparm driver and tests. - Add a papr-miscdev.h uapi header. - Prevent sys_rtas() from interfering with papr-vpd call sequences. - Handle -4 ("VPD changed") status in papr-vpd. - Include string_helpers.h in papr-vpd.c, per Michal Suchánek - Link to RFC: https://lore.kernel.org/r/20230822-papr-sys_rtas-vs-lockdown-v1-0-932623cf3c7b@linux.ibm.com --- b4-submit-tracking --- { "series": { "revision": 5, "change-id": "20230817-papr-sys_rtas-vs-lockdown-5c54505db792", "prefixes": [], "history": { "v1": [ "20230822-papr-sys_rtas-vs-lockdown-v1-0-932623cf3c7b@linux.ibm.com", "20231006-papr-sys_rtas-vs-lockdown-v1-0-3a36bfb66e2e@linux.ibm.com" ], "v2": [ "20231013-papr-sys_rtas-vs-lockdown-v2-0-ead01ce01722@linux.ibm.com" ], "v3": [ "20231025-papr-sys_rtas-vs-lockdown-v3-0-5eb04559e7d8@linux.ibm.com" ], "v4": [ "20231117-papr-sys_rtas-vs-lockdown-v4-0-b794d8cb8502@linux.ibm.com" ] } } }
nathanlynch
added a commit
to nathanlynch/linux
that referenced
this pull request
Dec 7, 2023
Add character devices that expose PAPR-specific system parameters and VPD to user space. 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. It also is too low-level in many cases: a single logical operation may require multiple sys_rtas() calls in succession to complete. This carries the risk that a process may exit while leaving an operation unfinished. It also means that callers must coordinate their use of the syscall for functions that cannot tolerate multiple concurrent clients, such as ibm,get-vpd. These are the general problems, but it's difficult to formulate a similarly general solution in the form of a single replacement ABI for sys_rtas(). Instead, each platform facility we expose to user space needs a specific interface that forms the kernel-user interactions at a higher level than individual RTAS calls. I've identified system parameter support as a high priority for this effort, since the software that communicates with the management console relies on it and therefore does not work at all with lockdown enabled on current kernels. VPD retrieval is also important (for licensing/entitlement things I think?), and serves as a good initial example of encapsulating sequence-based RTAS calls. So this series proposes a model for incrementally solving these issues by introducing a small pseries-specific "driver" for each of these platform functions. The new drivers expose these facilities to user space in ways that are compatible with lockdown, and they require no coordination between their clients. In preparation, per-function mutexes are added to the core RTAS code to serialize access to sequence-based RTAS functions. These prevent kernel-based sequences from interfering with each other, and they prevent sys_rtas() users from disrupting kernel-based users. The RTAS core enforces correct lock usage when lockdep is enabled. Both drivers could potentially support poll() methods to notify clients of changes to parameters or VPD that happen due to partition migration and other events. But that should be safe to leave for later, assuming there's any interest. I have made changes to librtas to prefer the new interfaces and verified that existing clients work correctly with the new code. A draft PR for that work is here: ibm-power-utilities/librtas#36 The user-space ABI has not changed since v1 of this series. I expect to propose at least one more small driver in this style for platform dump retrieval in a separate submission in the future. Other facilities may follow as needs are identified. To: Michael Ellerman <[email protected]> To: Nicholas Piggin <[email protected]> Cc: [email protected] Cc: Michal Suchánek <[email protected]> Cc: "Aneesh Kumar K.V (IBM)" <[email protected]> Cc: [email protected] Cc: [email protected] --- Changes in v6: - EDITME: describe what is new in this series revision. - EDITME: use bulletpoints and terse descriptions. - Link to v5: https://lore.kernel.org/r/20231207-papr-sys_rtas-vs-lockdown-v5-0-2ce965636a58@linux.ibm.com Changes in v5: - Add to the front of the queue another fix for a latent bug where sys_rtas() users can trigger a spurious warning backtrace. - Merge "powerpc/uapi: Export papr-miscdev.h header" into "Add papr-vpd character driver for VPD retrieval" so we don't temporarily expose the PAPR_MISCDEV_IOC_ID constant via UAPI without also updating the ioctl-number documentation. (Michael Ellerman) - Drop rtas_function_{un}lock() in favor of more explicit use of the new per-function mutexes; make rtas_ibm_get_vpd_lock extern for use by papr-vpd. - Assert that rtas_ibm_get_vpd_lock is held in rtas_ibm_get_vpd(). - Add example usage to "powerpc/rtas: Facilitate high-level call sequences". (Aneesh Kumar K.V) - Drop the now-unnecessary 04/13 "powerpc/rtas: Factor out function descriptor lookup". - Include document version when citing the PAPR+ specification throughout. (Michael Ellerman) - Add missing include directives to papr-vpd and papr-sysparm. (Michal Suchánek) - Fix spurious testcase failure in environments without a working ibm,set-system-parameter RTAS function. (Michael Ellerman) - Link to v4: https://lore.kernel.org/r/20231117-papr-sys_rtas-vs-lockdown-v4-0-b794d8cb8502@linux.ibm.com Changes in v4: - Fix latent issue in rtas_token_to_function() which causes boot-time crashes. - More small preparatory changes: a function table iterator and additional symbolic constants for RTAS function return values. - Use symbolic constants for ibm,get-vpd statuses in papr-vpd.c. - Add commentary to papr_vpd_ioc_create_handle() explaining choice to retrieve all VPD at file handle creation time instead of deferring it to the read handler. - Rebase on current powerpc/next. - Link to v3: https://lore.kernel.org/r/20231025-papr-sys_rtas-vs-lockdown-v3-0-5eb04559e7d8@linux.ibm.com Changes in v3: - Add new rtas_function_lock()/unlock() APIs and convert existing code to use them. - Convert papr-vpd to use rtas_function_lock()/unlock() instead of having sys_rtas() obtain a driver-private mutex. - Rebase on current powerpc/next. - Link to v2: https://lore.kernel.org/r/20231013-papr-sys_rtas-vs-lockdown-v2-0-ead01ce01722@linux.ibm.com Changes in v2: - Fix unused-but-set variable warning in papr-sysparm code. - Rebase on powerpc/next branch. - Link to v1: https://lore.kernel.org/r/20231006-papr-sys_rtas-vs-lockdown-v1-0-3a36bfb66e2e@linux.ibm.com Changes in v1 vs initial RFC: - Add papr-sysparm driver and tests. - Add a papr-miscdev.h uapi header. - Prevent sys_rtas() from interfering with papr-vpd call sequences. - Handle -4 ("VPD changed") status in papr-vpd. - Include string_helpers.h in papr-vpd.c, per Michal Suchánek - Link to RFC: https://lore.kernel.org/r/20230822-papr-sys_rtas-vs-lockdown-v1-0-932623cf3c7b@linux.ibm.com --- b4-submit-tracking --- # This section is used internally by b4 prep for tracking purposes. { "series": { "revision": 6, "change-id": "20230817-papr-sys_rtas-vs-lockdown-5c54505db792", "prefixes": [], "history": { "v1": [ "20230822-papr-sys_rtas-vs-lockdown-v1-0-932623cf3c7b@linux.ibm.com", "20231006-papr-sys_rtas-vs-lockdown-v1-0-3a36bfb66e2e@linux.ibm.com" ], "v2": [ "20231013-papr-sys_rtas-vs-lockdown-v2-0-ead01ce01722@linux.ibm.com" ], "v3": [ "20231025-papr-sys_rtas-vs-lockdown-v3-0-5eb04559e7d8@linux.ibm.com" ], "v4": [ "20231117-papr-sys_rtas-vs-lockdown-v4-0-b794d8cb8502@linux.ibm.com" ], "v5": [ "20231207-papr-sys_rtas-vs-lockdown-v5-0-2ce965636a58@linux.ibm.com" ] } } }
nathanlynch
added a commit
to nathanlynch/linux
that referenced
this pull request
Dec 12, 2023
Add character devices that expose PAPR-specific system parameters and VPD to user space. 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. It also is too low-level in many cases: a single logical operation may require multiple sys_rtas() calls in succession to complete. This carries the risk that a process may exit while leaving an operation unfinished. It also means that callers must coordinate their use of the syscall for functions that cannot tolerate multiple concurrent clients, such as ibm,get-vpd. These are the general problems, but it's difficult to formulate a similarly general solution in the form of a single replacement ABI for sys_rtas(). Instead, each platform facility we expose to user space needs a specific interface that forms the kernel-user interactions at a higher level than individual RTAS calls. I've identified system parameter support as a high priority for this effort, since the software that communicates with the management console relies on it and therefore does not work at all with lockdown enabled on current kernels. VPD retrieval is also important (for licensing/entitlement things I think?), and serves as a good initial example of encapsulating sequence-based RTAS calls. So this series proposes a model for incrementally solving these issues by introducing a small pseries-specific "driver" for each of these platform functions. The new drivers expose these facilities to user space in ways that are compatible with lockdown, and they require no coordination between their clients. In preparation, per-function mutexes are added to the core RTAS code to serialize access to sequence-based RTAS functions. These prevent kernel-based sequences from interfering with each other, and they prevent sys_rtas() users from disrupting kernel-based users. The RTAS core enforces correct lock usage when lockdep is enabled. Both drivers could potentially support poll() methods to notify clients of changes to parameters or VPD that happen due to partition migration and other events. But that should be safe to leave for later, assuming there's any interest. I have made changes to librtas to prefer the new interfaces and verified that existing clients work correctly with the new code. A draft PR for that work is here: ibm-power-utilities/librtas#36 The user-space ABI has not changed since v1 of this series. I expect to propose at least one more small driver in this style for platform dump retrieval in a separate submission in the future. Other facilities may follow as needs are identified. To: Michael Ellerman <[email protected]> To: Nicholas Piggin <[email protected]> Cc: [email protected] Cc: Michal Suchánek <[email protected]> Cc: "Aneesh Kumar K.V (IBM)" <[email protected]> Cc: [email protected] Cc: [email protected] --- Changes in v6: - Require FMODE_WRITE for setting system parameters in papr-sysparm and add a corresponding testcase. - Update existing sysparm testcases to open the device writable when attempting to set parameters. - Link to v5: https://lore.kernel.org/r/20231207-papr-sys_rtas-vs-lockdown-v5-0-2ce965636a58@linux.ibm.com Changes in v5: - Add to the front of the queue another fix for a latent bug where sys_rtas() users can trigger a spurious warning backtrace. - Merge "powerpc/uapi: Export papr-miscdev.h header" into "Add papr-vpd character driver for VPD retrieval" so we don't temporarily expose the PAPR_MISCDEV_IOC_ID constant via UAPI without also updating the ioctl-number documentation. (Michael Ellerman) - Drop rtas_function_{un}lock() in favor of more explicit use of the new per-function mutexes; make rtas_ibm_get_vpd_lock extern for use by papr-vpd. - Assert that rtas_ibm_get_vpd_lock is held in rtas_ibm_get_vpd(). - Add example usage to "powerpc/rtas: Facilitate high-level call sequences". (Aneesh Kumar K.V) - Drop the now-unnecessary 04/13 "powerpc/rtas: Factor out function descriptor lookup". - Include document version when citing the PAPR+ specification throughout. (Michael Ellerman) - Add missing include directives to papr-vpd and papr-sysparm. (Michal Suchánek) - Fix spurious testcase failure in environments without a working ibm,set-system-parameter RTAS function. (Michael Ellerman) - Link to v4: https://lore.kernel.org/r/20231117-papr-sys_rtas-vs-lockdown-v4-0-b794d8cb8502@linux.ibm.com Changes in v4: - Fix latent issue in rtas_token_to_function() which causes boot-time crashes. - More small preparatory changes: a function table iterator and additional symbolic constants for RTAS function return values. - Use symbolic constants for ibm,get-vpd statuses in papr-vpd.c. - Add commentary to papr_vpd_ioc_create_handle() explaining choice to retrieve all VPD at file handle creation time instead of deferring it to the read handler. - Rebase on current powerpc/next. - Link to v3: https://lore.kernel.org/r/20231025-papr-sys_rtas-vs-lockdown-v3-0-5eb04559e7d8@linux.ibm.com Changes in v3: - Add new rtas_function_lock()/unlock() APIs and convert existing code to use them. - Convert papr-vpd to use rtas_function_lock()/unlock() instead of having sys_rtas() obtain a driver-private mutex. - Rebase on current powerpc/next. - Link to v2: https://lore.kernel.org/r/20231013-papr-sys_rtas-vs-lockdown-v2-0-ead01ce01722@linux.ibm.com Changes in v2: - Fix unused-but-set variable warning in papr-sysparm code. - Rebase on powerpc/next branch. - Link to v1: https://lore.kernel.org/r/20231006-papr-sys_rtas-vs-lockdown-v1-0-3a36bfb66e2e@linux.ibm.com Changes in v1 vs initial RFC: - Add papr-sysparm driver and tests. - Add a papr-miscdev.h uapi header. - Prevent sys_rtas() from interfering with papr-vpd call sequences. - Handle -4 ("VPD changed") status in papr-vpd. - Include string_helpers.h in papr-vpd.c, per Michal Suchánek - Link to RFC: https://lore.kernel.org/r/20230822-papr-sys_rtas-vs-lockdown-v1-0-932623cf3c7b@linux.ibm.com --- b4-submit-tracking --- { "series": { "revision": 6, "change-id": "20230817-papr-sys_rtas-vs-lockdown-5c54505db792", "prefixes": [], "history": { "v1": [ "20230822-papr-sys_rtas-vs-lockdown-v1-0-932623cf3c7b@linux.ibm.com", "20231006-papr-sys_rtas-vs-lockdown-v1-0-3a36bfb66e2e@linux.ibm.com" ], "v2": [ "20231013-papr-sys_rtas-vs-lockdown-v2-0-ead01ce01722@linux.ibm.com" ], "v3": [ "20231025-papr-sys_rtas-vs-lockdown-v3-0-5eb04559e7d8@linux.ibm.com" ], "v4": [ "20231117-papr-sys_rtas-vs-lockdown-v4-0-b794d8cb8502@linux.ibm.com" ], "v5": [ "20231207-papr-sys_rtas-vs-lockdown-v5-0-2ce965636a58@linux.ibm.com" ] } } }
nathanlynch
added a commit
to nathanlynch/linux
that referenced
this pull request
Dec 12, 2023
Add character devices that expose PAPR-specific system parameters and VPD to user space. 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. It also is too low-level in many cases: a single logical operation may require multiple sys_rtas() calls in succession to complete. This carries the risk that a process may exit while leaving an operation unfinished. It also means that callers must coordinate their use of the syscall for functions that cannot tolerate multiple concurrent clients, such as ibm,get-vpd. These are the general problems, but it's difficult to formulate a similarly general solution in the form of a single replacement ABI for sys_rtas(). Instead, each platform facility we expose to user space needs a specific interface that forms the kernel-user interactions at a higher level than individual RTAS calls. I've identified system parameter support as a high priority for this effort, since the software that communicates with the management console relies on it and therefore does not work at all with lockdown enabled on current kernels. VPD retrieval is also important (for licensing/entitlement things I think?), and serves as a good initial example of encapsulating sequence-based RTAS calls. So this series proposes a model for incrementally solving these issues by introducing a small pseries-specific "driver" for each of these platform functions. The new drivers expose these facilities to user space in ways that are compatible with lockdown, and they require no coordination between their clients. In preparation, per-function mutexes are added to the core RTAS code to serialize access to sequence-based RTAS functions. These prevent kernel-based sequences from interfering with each other, and they prevent sys_rtas() users from disrupting kernel-based users. The RTAS core enforces correct lock usage when lockdep is enabled. Both drivers could potentially support poll() methods to notify clients of changes to parameters or VPD that happen due to partition migration and other events. But that should be safe to leave for later, assuming there's any interest. I have made changes to librtas to prefer the new interfaces and verified that existing clients work correctly with the new code. A draft PR for that work is here: ibm-power-utilities/librtas#36 The user-space ABI has not changed since v1 of this series. I expect to propose at least one more small driver in this style for platform dump retrieval in a separate submission in the future. Other facilities may follow as needs are identified. To: Michael Ellerman <[email protected]> To: Nicholas Piggin <[email protected]> Cc: [email protected] Cc: Michal Suchánek <[email protected]> Cc: "Aneesh Kumar K.V (IBM)" <[email protected]> Cc: [email protected] Cc: [email protected] --- Changes in v7: - EDITME: describe what is new in this series revision. - EDITME: use bulletpoints and terse descriptions. - Link to v6: https://lore.kernel.org/r/20231212-papr-sys_rtas-vs-lockdown-v6-0-e9eafd0c8c6c@linux.ibm.com Changes in v6: - Require FMODE_WRITE for setting system parameters in papr-sysparm and add a corresponding testcase. - Update existing sysparm testcases to open the device writable when attempting to set parameters. - Link to v5: https://lore.kernel.org/r/20231207-papr-sys_rtas-vs-lockdown-v5-0-2ce965636a58@linux.ibm.com Changes in v5: - Add to the front of the queue another fix for a latent bug where sys_rtas() users can trigger a spurious warning backtrace. - Merge "powerpc/uapi: Export papr-miscdev.h header" into "Add papr-vpd character driver for VPD retrieval" so we don't temporarily expose the PAPR_MISCDEV_IOC_ID constant via UAPI without also updating the ioctl-number documentation. (Michael Ellerman) - Drop rtas_function_{un}lock() in favor of more explicit use of the new per-function mutexes; make rtas_ibm_get_vpd_lock extern for use by papr-vpd. - Assert that rtas_ibm_get_vpd_lock is held in rtas_ibm_get_vpd(). - Add example usage to "powerpc/rtas: Facilitate high-level call sequences". (Aneesh Kumar K.V) - Drop the now-unnecessary 04/13 "powerpc/rtas: Factor out function descriptor lookup". - Include document version when citing the PAPR+ specification throughout. (Michael Ellerman) - Add missing include directives to papr-vpd and papr-sysparm. (Michal Suchánek) - Fix spurious testcase failure in environments without a working ibm,set-system-parameter RTAS function. (Michael Ellerman) - Link to v4: https://lore.kernel.org/r/20231117-papr-sys_rtas-vs-lockdown-v4-0-b794d8cb8502@linux.ibm.com Changes in v4: - Fix latent issue in rtas_token_to_function() which causes boot-time crashes. - More small preparatory changes: a function table iterator and additional symbolic constants for RTAS function return values. - Use symbolic constants for ibm,get-vpd statuses in papr-vpd.c. - Add commentary to papr_vpd_ioc_create_handle() explaining choice to retrieve all VPD at file handle creation time instead of deferring it to the read handler. - Rebase on current powerpc/next. - Link to v3: https://lore.kernel.org/r/20231025-papr-sys_rtas-vs-lockdown-v3-0-5eb04559e7d8@linux.ibm.com Changes in v3: - Add new rtas_function_lock()/unlock() APIs and convert existing code to use them. - Convert papr-vpd to use rtas_function_lock()/unlock() instead of having sys_rtas() obtain a driver-private mutex. - Rebase on current powerpc/next. - Link to v2: https://lore.kernel.org/r/20231013-papr-sys_rtas-vs-lockdown-v2-0-ead01ce01722@linux.ibm.com Changes in v2: - Fix unused-but-set variable warning in papr-sysparm code. - Rebase on powerpc/next branch. - Link to v1: https://lore.kernel.org/r/20231006-papr-sys_rtas-vs-lockdown-v1-0-3a36bfb66e2e@linux.ibm.com Changes in v1 vs initial RFC: - Add papr-sysparm driver and tests. - Add a papr-miscdev.h uapi header. - Prevent sys_rtas() from interfering with papr-vpd call sequences. - Handle -4 ("VPD changed") status in papr-vpd. - Include string_helpers.h in papr-vpd.c, per Michal Suchánek - Link to RFC: https://lore.kernel.org/r/20230822-papr-sys_rtas-vs-lockdown-v1-0-932623cf3c7b@linux.ibm.com --- b4-submit-tracking --- # This section is used internally by b4 prep for tracking purposes. { "series": { "revision": 7, "change-id": "20230817-papr-sys_rtas-vs-lockdown-5c54505db792", "prefixes": [], "history": { "v1": [ "20230822-papr-sys_rtas-vs-lockdown-v1-0-932623cf3c7b@linux.ibm.com", "20231006-papr-sys_rtas-vs-lockdown-v1-0-3a36bfb66e2e@linux.ibm.com" ], "v2": [ "20231013-papr-sys_rtas-vs-lockdown-v2-0-ead01ce01722@linux.ibm.com" ], "v3": [ "20231025-papr-sys_rtas-vs-lockdown-v3-0-5eb04559e7d8@linux.ibm.com" ], "v4": [ "20231117-papr-sys_rtas-vs-lockdown-v4-0-b794d8cb8502@linux.ibm.com" ], "v5": [ "20231207-papr-sys_rtas-vs-lockdown-v5-0-2ce965636a58@linux.ibm.com" ], "v6": [ "20231212-papr-sys_rtas-vs-lockdown-v6-0-e9eafd0c8c6c@linux.ibm.com" ] } } }
|
Kernel submission is merged. |
Add a utility that can quickly validate a development build against vpdupdate, which exercises the rtas_get_vpd() API. This is a high-level test that needs superuser priveleges to run, so it's not suitable for the development test suite. Signed-off-by: Nathan Lynch <[email protected]>
Add a utility that can quickly validate a development build against the activate_firmware command from powerpc-utils, which exercises the rtas_get_sysparm() API. This is a high-level test that needs superuser priveleges to run, so it's not suitable for the development test suite. (Note that despite its name, the way we invoke the command does not alter any system or firmware configuration, it only queries a system parameter.) Signed-off-by: Nathan Lynch <[email protected]>
Make these functions available outside of syscall_calls.c, marking them hidden so that they aren't exposed in the library ABI. The implementations of librtas APIs will move into separate C files as they gain support for new interfaces offered by the kernel. Signed-off-by: Nathan Lynch <[email protected]>
This code will gain the ability to retrieve VPD using a different interface exposed by newer kernels. This will be a lot of additional code, so move it out of syscall_calls.c. Signed-off-by: Nathan Lynch <[email protected]>
This code will gain the ability to access system parameters using a different interface exposed by newer kernels. This will involve adding a nontrivial amount of code, so move it out of syscall_calls.c. Signed-off-by: Nathan Lynch <[email protected]>
This is a common header used by other kernel uapi headers that we will copy into the source tree. Signed-off-by: Nathan Lynch <[email protected]>
Change rtas_get_vpd() to prefer the /dev/papr-vpd character device expected in Linux v6.8. On the first invocation of rtas_get_vpd(), probe for the new ABI and initialize an internal function pointer according to the result. Use pthread_once() to ensure that this probe step is performed atomically and only once. It would not make sense to re-probe (and potentially update the implementation) on every call, since the implementations differ in the way state for the call sequence is maintained. Assuming the new ABI is available: upon first call to rtas_get_vpd(), open /dev/papr-vpd and obtain a file descriptor using the PAPR_VPD_CREATE_HANDLE ioctl() command. This file descriptor is a reference to the VPD returned from a complete ibm,get-vpd call sequence. Subsequent calls sequentially read the VPD from the fd, which is closed once EOF is reached. To existing users of rtas_get_vpd(), the new implementation is indistinguishable from the old one, with one exception: * When using the rtas() syscall on current systems, RTAS advances the sequence number by a fixed interval on each call in a sequence. This is visible in the values returned in the 'seq_next' out parameter. * When using /dev/papr-vpd, the value returned in 'seq_next' does not change between calls; librtas treats it as a "handle" for a sequence in progress. In PAPR there is no meaning attached to the value returned in the 'seq_next' out parameter, and there is no requirement that it must change or increment on each call. No user should be relying on the behavior of this aspect of the interface to judge the status of a sequence. I have verified that an unmodified vpdupdate command from a distro lsvpd package works correctly when linked to a librtas.so with this change. This is the primary (and perhaps only) user of rtas_get_vpd(). For now, carry a copy of the kernel uapi header. Signed-off-by: Nathan Lynch <[email protected]>
Change rtas_get_sysparm() and rtas_set_sysparm() to prefer the /dev/papr-sysparm character device expected in Linux v6.8. On the first invocation of either function, probe for the new ABI and initialize internal function pointers according to the result. Use pthread_once() to ensure that this initialization step is performed atomically and only once. When /dev/papr-sysparm is available, use its PAPR_SYSPARM_IOC_GET and PAPR_SYSPARM_IOC_SET ioctl commands to retrieve and update system parameters. Most of the complexity of calling RTAS is handled internally to the kernel and the ioctl follows Linux conventions, returning 0 on success or -1 w/errno on failure. On failure, back-convert the errno to an RTAS status value that callers will recognize. For now, carry a copy of the kernel uapi header. Signed-off-by: Nathan Lynch <[email protected]>
nathanlynch
force-pushed
the
topic/new-uapi-support
branch
from
2699103 to
7af7d7f
Compare
|
Thanks for the update. Still catching up from the holiday, but I will get this queued soon. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Latest draft of support for proposed character device APIs for VPD and system parameters.
This is a draft PR and will likely need updates according to how the kernel submission goes.
Link to kernel submission:
https://lore.kernel.org/linuxppc-dev/20231006-papr-sys_rtas-vs-lockdown-v1-0-3a36bfb66e2e@linux.ibm.com/T/#m53331fa7cc95245a94d4ab5a288be21305eb5053