linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: "Michal Suchánek" <msuchanek@suse.de>
To: Nathan Lynch <nathanl@linux.ibm.com>
Cc: gcwilson@linux.ibm.com, linuxppc-dev@lists.ozlabs.org,
	Nicholas Piggin <npiggin@gmail.com>,
	tyreld@linux.ibm.com
Subject: Re: [PATCH RFC] powerpc/rtas: Make it possible to disable sys_rtas
Date: Thu, 7 Sep 2023 19:19:07 +0200	[thread overview]
Message-ID: <20230907171907.GC8826@kitsune.suse.cz> (raw)
In-Reply-To: <878r9ivsbn.fsf@li-e15d104c-2135-11b2-a85c-d7ef17e56be6.ibm.com>

On Thu, Sep 07, 2023 at 11:52:44AM -0500, Nathan Lynch wrote:
> Michal Suchánek <msuchanek@suse.de> writes:
> > On Wed, Sep 06, 2023 at 02:34:59PM -0500, Nathan Lynch wrote:
> >> Michal Suchanek <msuchanek@suse.de> writes:
> >> 
> >> > Additional patch suggestion to go with the rtas devices:
> >> >
> >> > -----------------------------------------------------------------------
> >> >
> >> > With most important rtas functions available through different
> >> > interfaces the sys_rtas interface can be disabled completely.
> >> >
> >> > Do not remove it for now to make it possible to run older versions of
> >> > userspace tools that don't support other interfaces.
> >> 
> >> Thanks. I hope making sys_rtas on/off-configurable will make sense
> >> eventually, and I expect this series to get us closer to that. But to me
> >> it seems too early and too coarse. A kernel built with RTAS_SYSCALL=n is
> >> not something I'd want to support or run in production soon. It would
> >> break too many known use cases, and likely some unknown ones as well.
> >
> > There are about 3 known use cases that absolutely need access by other
> > means than sys_rtas to work with lockdown, and about other 3 that would
> > work either way.
> 
> How do you figure that? I count 11 librtas APIs that use work areas (and
> therefore /dev/mem) that are definitely broken under lockdown. Maybe a
> couple of them are unused.

I am referring to this list of known uses:

https://github.com/ibm-power-utilities/librtas/issues/29

rtas_get_vpd is used by lsvpd (through libvpd and librtas)
rtas_platform_dump and rtas_get_indices is used by ppc64-diag
rtas_cfg_connector is used by powerpc-utils and is planned to be
replaced by in-kernel solution

That covers the complex cases.

rtas_set_sysparm is used by ppc64-diag and powerpc-utils
rtas_set_dynamic_indicator, rtas_get_dynamic_sensor are used by
ppc64-diag (related to rtas_get_indices)
rtas_errinjct + open/close are used by powerpc-utils

That's the simple cases.

Additional discussion here https://github.com/linuxppc/issues/issues/252

> > That's not so staggering that it could not be implemented in the kernel
> > from the start.
> > How long it will take for the known userspace users to catch up is
> > anotehr questio but again it's something that can be addressed.
> >
> > Making it possible to turn off sys_rtas will make it easier to uncover
> > the not yet known cases.
> 
> This is also true of making the configuration more granular than on or
> off. You would be free to disallow all calls if desired.
> 
> > What people want to support depends a lot on what is converted, and also
> > the situation of the distribution in question. Fast-rollong
> > distributions may want only the new interface quite soon, and so may
> > distributions that are starting development of new release.
> >
> > All this makes sense only if there is a plan to discontinue sys_rtas
> > entirely. For the simple calls that don't need data buffers it's still
> > usable.
> 
> I don't understand. How would it remain usable for the simple calls if
> it can be completely disabled?

Either the goal is to completely remove sys_rtas, and then an option for
disabling it is helpful for uncovering unexpected problems. Or thre
isn't a goal of sys_rtas removal, and then there is no point in having
an option to disable it, and it can be used for calls that don't need
buffers indefinitely.

Thanks

Michal

  reply	other threads:[~2023-09-07 17:20 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-22 21:33 [PATCH RFC 0/2] powerpc/pseries: new character devices for RTAS functions Nathan Lynch via B4 Relay
2023-08-22 21:33 ` [PATCH RFC 1/2] powerpc/pseries: papr-vpd char driver for VPD retrieval Nathan Lynch via B4 Relay
2023-08-30  7:29   ` Michal Suchánek
2023-08-31  5:34     ` Michael Ellerman
2023-08-31 10:38       ` Michal Suchánek
2023-08-31 11:37         ` Michael Ellerman
2023-08-31 11:44           ` Michal Suchánek
2023-08-31 17:59             ` Nathan Lynch
2023-09-04  7:20               ` Michal Suchánek
2023-09-05  2:42                 ` Michael Ellerman
2023-09-05  8:24                   ` Michal Suchánek
2023-08-31 11:35       ` Michal Suchánek
2023-09-04  7:48       ` Michal Suchánek
2023-08-31 15:52     ` Nathan Lynch
2023-09-06  9:19   ` Michal Suchánek
2023-08-22 21:33 ` [PATCH RFC 2/2] powerpc/selftests: add test for papr-vpd Nathan Lynch via B4 Relay
2023-08-24  6:20   ` Russell Currey
2023-08-24 11:51     ` Nathan Lynch
2023-09-06  9:30 ` [PATCH RFC 0/2] powerpc/pseries: new character devices for RTAS functions Michal Suchánek
2023-09-06 12:08 ` [PATCH RFC] powerpc/rtas: Make it possible to disable sys_rtas Michal Suchanek
2023-09-06 19:34   ` Nathan Lynch
2023-09-07 16:01     ` Michal Suchánek
2023-09-07 16:52       ` Nathan Lynch
2023-09-07 17:19         ` Michal Suchánek [this message]
2023-09-08 17:48           ` Nathan Lynch

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230907171907.GC8826@kitsune.suse.cz \
    --to=msuchanek@suse.de \
    --cc=gcwilson@linux.ibm.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=nathanl@linux.ibm.com \
    --cc=npiggin@gmail.com \
    --cc=tyreld@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).