From edca06b8d6fbcbb9f8c3dd0b0269413f03d6a91e Mon Sep 17 00:00:00 2001
From: Nathan Lynch <nathanl@linux.ibm.com>
Date: Thu, 17 Aug 2023 11:34:16 -0500
Subject: [PATCH] powerpc/pseries: new character devices for RTAS functions
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This is a proposal for adding chardev-based access to a select subset
of RTAS functions on the pseries platform.

The problem: important platform features are enabled on Linux VMs
through the powerpc-specific rtas() syscall in combination with
writeable mappings of /dev/mem. In typical usage, this is encapsulated
behind APIs provided by the librtas library. This paradigm is
incompatible with lockdown, which prohibits /dev/mem access.

The solution I'm working on is to add a small pseries-specific
"driver" for each functional area, exposing the relevant features to
user space in ways that are compatible with lockdown. In most of these
areas, I believe it's possible to change librtas to prefer the new
chardev interfaces without disrupting existing users.

I've broken down the affected functions into the following areas and
priorities:

High priority:
* VPD retrieval.
* System parameters: retrieval and update.

Medium priority:
* Platform dump retrieval.
* Light path diagnostics (get/set-dynamic-indicator,
  get-dynamic-sensor-state, get-indices).

Low priority (may never happen):
* Error injection: would have to be carefully restricted.
* Physical attestation: no known users.
* LPAR perftools: no known users.

Out of scope:
* DLPAR (configure-connector et al): involves device tree updates
  which must be handled entirely in-kernel for lockdown. This is the
  object of a separate effort.

See https://github.com/ibm-power-utilities/librtas/issues/29 for more
details.

In this RFC, I've included a single driver for VPD retrieval. Clients
use ioctl() to obtain a file descriptor-based handle for the VPD they
want. I think this could be a good model for the other areas too, but
I'd like to get opinions on it.

In the next iteration I expect to add a separate driver for system
parameters.

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

https://lore.kernel.org/linuxppc-dev/20220730000458.130938-1-nathanl@linux.ibm.com/

To: Michael Ellerman <mpe@ellerman.id.au>
To: Nicholas Piggin <npiggin@gmail.com>
To: Michal Suchánek <msuchanek@suse.de>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: tyreld@linux.ibm.com
Cc: gcwilson@linux.ibm.com

---
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"
      ]
    }
  }
}