Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

transition away from /dev/mem #29

Open
nathanlynch opened this issue Aug 18, 2022 · 2 comments
Open

transition away from /dev/mem #29

nathanlynch opened this issue Aug 18, 2022 · 2 comments

Comments

@nathanlynch
Copy link
Contributor

nathanlynch commented Aug 18, 2022

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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.

nathanlynch added a commit to nathanlynch/linuxppc-ci that referenced this issue Aug 17, 2023
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 ibm-power-utilities/librtas#29 for more
details.

In this initial series, I've included just a 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.

For reference, I floated a different approach for system parameters
here:

https://lore.kernel.org/linuxppc-dev/[email protected]/

--- b4-submit-tracking ---
{
  "series": {
    "revision": 1,
    "change-id": "20230817-papr-sys_rtas-vs-lockdown-5c54505db792",
    "prefixes": [
      "RFC"
    ]
  }
}
nathanlynch added a commit to nathanlynch/linuxppc-ci that referenced this issue Aug 22, 2023
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 ibm-power-utilities/librtas#29 for more
details.

In this initial series, I've included just a 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.

For reference, I floated a different approach for system parameters
here:

https://lore.kernel.org/linuxppc-dev/[email protected]/

--- b4-submit-tracking ---
{
  "series": {
    "revision": 1,
    "change-id": "20230817-papr-sys_rtas-vs-lockdown-5c54505db792",
    "prefixes": [
      "RFC"
    ]
  }
}
nathanlynch added a commit to nathanlynch/linuxppc-ci that referenced this issue Aug 22, 2023
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 ibm-power-utilities/librtas#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/[email protected]/

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/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": [
      "RFC"
    ],
    "history": {
      "v1": [
        "20230822-papr-sys_rtas-vs-lockdown-v1-0-932623cf3c7b@linux.ibm.com"
      ]
    }
  }
}
nathanlynch added a commit to nathanlynch/linuxppc-ci that referenced this issue Sep 7, 2023
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 ibm-power-utilities/librtas#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/[email protected]/

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:
- include string_helpers.h in papr-vpd.c, per Michal Suchánek
- Link to v1: 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": [
      "RFC"
    ],
    "history": {
      "v1": [
        "20230822-papr-sys_rtas-vs-lockdown-v1-0-932623cf3c7b@linux.ibm.com"
      ]
    }
  }
}
nathanlynch added a commit to nathanlynch/linuxppc-ci that referenced this issue Sep 22, 2023
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 ibm-power-utilities/librtas#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/[email protected]/

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:
- include string_helpers.h in papr-vpd.c, per Michal Suchánek
- Link to v1: 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": [
      "RFC"
    ],
    "history": {
      "v1": [
        "20230822-papr-sys_rtas-vs-lockdown-v1-0-932623cf3c7b@linux.ibm.com"
      ]
    }
  }
}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant