Re: [PATCH] powerpc/powermac/pfunc_base: Fix refcount leak bug in macio_gpio_init_one()

[Benjamin Herrenschmidt]

On Sat, 2022-07-16 at 15:31 +0800, Liang He wrote:
> We should call of_node_put() for the reference 'gparent' escaped
> out of the for_each_child_of_node() as it has increased the refcount.

Same comment as before. That stuff happens once at boot, there's never
any dynamic allocation/deallocation of these, they just don't matter,
but feel free  :-)

> Fixes: 5b9ca526917b ("[PATCH] 3/5 powerpc: Add platform functions
> interpreter")
> Signed-off-by: Liang He 
> ---
>  arch/powerpc/platforms/powermac/pfunc_base.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/powerpc/platforms/powermac/pfunc_base.c
> b/arch/powerpc/platforms/powermac/pfunc_base.c
> index 9c2947a3edd5..085e0ad20eba 100644
> --- a/arch/powerpc/platforms/powermac/pfunc_base.c
> +++ b/arch/powerpc/platforms/powermac/pfunc_base.c
> @@ -136,6 +136,8 @@ static void __init macio_gpio_init_one(struct
> macio_chip *macio)
>   for_each_child_of_node(gparent, gp)
>   pmf_do_functions(gp, NULL, 0, PMF_FLAGS_ON_INIT, NULL);
>  
> + of_node_put(gparent);
> +
>   /* Note: We do not at this point implement the "at sleep" or
> "at wake"
>* functions. I yet to find any for GPIOs anyway
>*/

Re: [PATCH] powerpc/powermac/udbg_scc: Fix refcount leak bug in udbg_scc_init()

[Benjamin Herrenschmidt]

On Sat, 2022-07-16 at 15:43 +0800, Liang He wrote:
> During the iteration of for_each_child_of_node(), we need to call
> of_node_put() for the old references stored in to 'ch_def' and 'ch_a'
> as their refcounters have been increased in last iteration.

None of these matter since those nodes are never *ever* released and
those machines don't use dynamic node allocation but ...

> Fixes: 51d3082fe6e5 ("[PATCH] powerpc: Unify udbg (#2)")
> Signed-off-by: Liang He 
> ---
>  arch/powerpc/platforms/powermac/udbg_scc.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/powerpc/platforms/powermac/udbg_scc.c
> b/arch/powerpc/platforms/powermac/udbg_scc.c
> index 734df5a32f99..1b7c39e841ee 100644
> --- a/arch/powerpc/platforms/powermac/udbg_scc.c
> +++ b/arch/powerpc/platforms/powermac/udbg_scc.c
> @@ -81,10 +81,14 @@ void __init udbg_scc_init(int force_scc)
>   if (path != NULL)
>   stdout = of_find_node_by_path(path);
>   for_each_child_of_node(escc, ch) {
> - if (ch == stdout)
> + if (ch == stdout) {
> + of_node_put(ch_def);
>   ch_def = of_node_get(ch);
> - if (of_node_name_eq(ch, "ch-a"))
> + }
> + if (of_node_name_eq(ch, "ch-a")) {
> + of_node_put(ch_a);
>   ch_a = of_node_get(ch);
> + }
>   }
>   if (ch_def == NULL && !force_scc)
>   goto bail;

[PATCH v4] PCI/ERR: Use pcie_aer_is_native() to judge whether OS owns AER

[Zhuo Chen]

Use pcie_aer_is_native() in place of "host->native_aer ||
pcie_ports_native" to judge whether OS has native control of AER
in aer_root_reset() and pcie_do_recovery().

Replace "dev->aer_cap && (pcie_ports_native || host->native_aer)" in
get_port_device_capability() with pcie_aer_is_native(), which has no
functional changes.

Signed-off-by: Zhuo Chen 
---
Changelog:
v4:
- Use pcie_aer_is_native() instead in aer_root_reset().
v3:
- Simplify why we use pcie_aer_is_native().
- Revert modification of pci_aer_clear_nonfatal_status() and comments.
v2:
- Add details and note in commit log.
---
 drivers/pci/pcie/aer.c  | 5 ++---
 drivers/pci/pcie/err.c  | 3 +--
 drivers/pci/pcie/portdrv_core.c | 3 +--
 3 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
index 7952e5efd6cf..796810c49008 100644
--- a/drivers/pci/pcie/aer.c
+++ b/drivers/pci/pcie/aer.c
@@ -1383,7 +1383,6 @@ static pci_ers_result_t aer_root_reset(struct pci_dev 
*dev)
int type = pci_pcie_type(dev);
struct pci_dev *root;
int aer;
-   struct pci_host_bridge *host = pci_find_host_bridge(dev->bus);
u32 reg32;
int rc;
 
@@ -1404,7 +1403,7 @@ static pci_ers_result_t aer_root_reset(struct pci_dev 
*dev)
 */
aer = root ? root->aer_cap : 0;
 
-   if ((host->native_aer || pcie_ports_native) && aer) {
+   if (pcie_aer_is_native(dev) && aer) {
/* Disable Root's interrupt in response to error messages */
pci_read_config_dword(root, aer + PCI_ERR_ROOT_COMMAND, );
reg32 &= ~ROOT_PORT_INTR_ON_MESG_MASK;
@@ -1423,7 +1422,7 @@ static pci_ers_result_t aer_root_reset(struct pci_dev 
*dev)
pci_is_root_bus(dev->bus) ? "Root" : "Downstream", rc);
}
 
-   if ((host->native_aer || pcie_ports_native) && aer) {
+   if (pcie_aer_is_native(dev) && aer) {
/* Clear Root Error Status */
pci_read_config_dword(root, aer + PCI_ERR_ROOT_STATUS, );
pci_write_config_dword(root, aer + PCI_ERR_ROOT_STATUS, reg32);
diff --git a/drivers/pci/pcie/err.c b/drivers/pci/pcie/err.c
index 0c5a143025af..121a53338e44 100644
--- a/drivers/pci/pcie/err.c
+++ b/drivers/pci/pcie/err.c
@@ -184,7 +184,6 @@ pci_ers_result_t pcie_do_recovery(struct pci_dev *dev,
int type = pci_pcie_type(dev);
struct pci_dev *bridge;
pci_ers_result_t status = PCI_ERS_RESULT_CAN_RECOVER;
-   struct pci_host_bridge *host = pci_find_host_bridge(dev->bus);
 
/*
 * If the error was detected by a Root Port, Downstream Port, RCEC,
@@ -243,7 +242,7 @@ pci_ers_result_t pcie_do_recovery(struct pci_dev *dev,
 * it is responsible for clearing this status.  In that case, the
 * signaling device may not even be visible to the OS.
 */
-   if (host->native_aer || pcie_ports_native) {
+   if (pcie_aer_is_native(dev)) {
pcie_clear_device_status(dev);
pci_aer_clear_nonfatal_status(dev);
}
diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c
index 604feeb84ee4..98c18f4a01b2 100644
--- a/drivers/pci/pcie/portdrv_core.c
+++ b/drivers/pci/pcie/portdrv_core.c
@@ -221,8 +221,7 @@ static int get_port_device_capability(struct pci_dev *dev)
}
 
 #ifdef CONFIG_PCIEAER
-   if (dev->aer_cap && pci_aer_available() &&
-   (pcie_ports_native || host->native_aer)) {
+   if (pcie_aer_is_native(dev) && pci_aer_available()) {
services |= PCIE_PORT_SERVICE_AER;
 
/*
-- 
2.30.1 (Apple Git-130)

Re: [PATCH v3 1/2] lib: generic accessor functions for arch keystore

[Michael Ellerman]

Hi Greg,

gjo...@linux.vnet.ibm.com writes:
> From: Greg Joyce 
>
> Generic kernel subsystems may rely on platform specific persistent
> KeyStore to store objects containing sensitive key material. In such case,
> they need to access architecture specific functions to perform read/write
> operations on these variables.
>
> Define the generic variable read/write prototypes to be implemented by
> architecture specific versions. The default(weak) implementations of
> these prototypes return -EOPNOTSUPP unless overridden by architecture
> versions.
>
> Signed-off-by: Greg Joyce 
> ---
>  include/linux/arch_vars.h | 23 +++
>  lib/Makefile  |  2 +-
>  lib/arch_vars.c   | 25 +
>  3 files changed, 49 insertions(+), 1 deletion(-)
>  create mode 100644 include/linux/arch_vars.h
>  create mode 100644 lib/arch_vars.c

I don't think "arch" is the right level of abstraction here.

There isn't a standard way to get these variables across a given arch,
they're not defined in the architecture specification etc.

As demonstrated in your patch 2, on powerpc they are coming from a
platform level pseudo device (provided by the PowerVM hypervisor). But
they would come from elsewhere on a bare metal system.

And you could imagine other architectures could support multiple ways to
retrieve these kind of variables from various different places, possibly
more than one place on a given system.

So I think at least you want a way for any device to register itself as
able to provide these variables. Possibly with a chain of handlers,
something like the sys_off_handlers, or maybe there only ever needs to
be one provider, the way pm_power_off (used to) work.

Looking at your patch to block/sed-opal.c:

  
https://lore.kernel.org/all/20220718210156.1535955-4-gjo...@linux.vnet.ibm.com/

It seems like the calls to these arch routines are closely tied to calls
to the keyring API. Should this functionality be part of the keyring
API?

At a mininmum I think you need to get much wider review on something
like this. So I'd suggest the keyring folks and as Michal pointed out,
this seems a bit like EFI variables so it would be good to Cc the
EFI/EFI variable folks.

cheers

[PATCH v8 27/31] Kbuild: add Rust support

[Miguel Ojeda]

Having all the new files in place, we now enable Rust support
in the build system, including `Kconfig` entries related to Rust,
the Rust configuration printer, the target specification
generation script, the version detection script and a few
other bits.

Co-developed-by: Alex Gaynor 
Signed-off-by: Alex Gaynor 
Co-developed-by: Finn Behrens 
Signed-off-by: Finn Behrens 
Co-developed-by: Adam Bratschi-Kaye 
Signed-off-by: Adam Bratschi-Kaye 
Co-developed-by: Wedson Almeida Filho 
Signed-off-by: Wedson Almeida Filho 
Co-developed-by: Michael Ellerman 
Signed-off-by: Michael Ellerman 
Co-developed-by: Sven Van Asbroeck 
Signed-off-by: Sven Van Asbroeck 
Co-developed-by: Gary Guo 
Signed-off-by: Gary Guo 
Co-developed-by: Boris-Chengbiao Zhou 
Signed-off-by: Boris-Chengbiao Zhou 
Co-developed-by: Boqun Feng 
Signed-off-by: Boqun Feng 
Co-developed-by: Douglas Su 
Signed-off-by: Douglas Su 
Co-developed-by: Dariusz Sosnowski 
Signed-off-by: Dariusz Sosnowski 
Co-developed-by: Antonio Terceiro 
Signed-off-by: Antonio Terceiro 
Co-developed-by: Daniel Xu 
Signed-off-by: Daniel Xu 
Co-developed-by: Miguel Cano 
Signed-off-by: Miguel Cano 
Co-developed-by: David Gow 
Signed-off-by: David Gow 
Co-developed-by: Tiago Lam 
Signed-off-by: Tiago Lam 
Co-developed-by: Björn Roy Baron 
Signed-off-by: Björn Roy Baron 
Co-developed-by: Martin Rodriguez Reboredo 
Signed-off-by: Martin Rodriguez Reboredo 
Signed-off-by: Miguel Ojeda 
---
 .gitignore   |   6 +
 .rustfmt.toml|  12 +
 Makefile | 172 +++-
 arch/Kconfig |   6 +
 arch/arm/Kconfig |   1 +
 arch/arm64/Kconfig   |   1 +
 arch/powerpc/Kconfig |   1 +
 arch/riscv/Kconfig   |   1 +
 arch/riscv/Makefile  |   5 +
 arch/um/Kconfig  |   1 +
 arch/x86/Kconfig |   1 +
 arch/x86/Makefile|  10 +
 include/linux/compiler_types.h   |   6 +-
 init/Kconfig |  46 +-
 lib/Kconfig.debug|  82 
 rust/.gitignore  |  10 +
 rust/Makefile| 415 +++
 rust/bindgen_parameters  |  21 +
 scripts/.gitignore   |   1 +
 scripts/Kconfig.include  |   6 +-
 scripts/Makefile |   3 +
 scripts/Makefile.build   |  60 +++
 scripts/Makefile.debug   |  10 +
 scripts/Makefile.host|  34 +-
 scripts/Makefile.lib |  12 +
 scripts/Makefile.modfinal|   8 +-
 scripts/cc-version.sh|  12 +-
 scripts/generate_rust_target.rs  | 232 +++
 scripts/is_rust_module.sh|  16 +
 scripts/kconfig/confdata.c   |  75 
 scripts/min-tool-version.sh  |   6 +
 scripts/rust-is-available-bindgen-libclang.h |   2 +
 scripts/rust-is-available.sh | 160 +++
 33 files changed, 1408 insertions(+), 26 deletions(-)
 create mode 100644 .rustfmt.toml
 create mode 100644 rust/.gitignore
 create mode 100644 rust/Makefile
 create mode 100644 rust/bindgen_parameters
 create mode 100644 scripts/generate_rust_target.rs
 create mode 100755 scripts/is_rust_module.sh
 create mode 100644 scripts/rust-is-available-bindgen-libclang.h
 create mode 100755 scripts/rust-is-available.sh

diff --git a/.gitignore b/.gitignore
index 265959544978..5da004814678 100644
--- a/.gitignore
+++ b/.gitignore
@@ -37,6 +37,8 @@
 *.o
 *.o.*
 *.patch
+*.rmeta
+*.rsi
 *.s
 *.so
 *.so.dbg
@@ -97,6 +99,7 @@ modules.order
 !.gitattributes
 !.gitignore
 !.mailmap
+!.rustfmt.toml
 
 #
 # Generated include files
@@ -162,3 +165,6 @@ x509.genkey
 
 # Documentation toolchain
 sphinx_*/
+
+# Rust analyzer configuration
+/rust-project.json
diff --git a/.rustfmt.toml b/.rustfmt.toml
new file mode 100644
index ..3de5cc497465
--- /dev/null
+++ b/.rustfmt.toml
@@ -0,0 +1,12 @@
+edition = "2021"
+newline_style = "Unix"
+
+# Unstable options that help catching some mistakes in formatting and that we 
may want to enable
+# when they become stable.
+#
+# They are kept here since they are useful to run from time to time.
+#format_code_in_doc_comments = true
+#reorder_impl_items = true
+#comment_width = 100
+#wrap_comments = true
+#normalize_comments = true
diff --git a/Makefile b/Makefile
index df92892325ae..cd1d545f316b 100644
--- a/Makefile
+++ b/Makefile
@@ -120,6 +120,15 @@ endif
 
 export KBUILD_CHECKSRC
 
+# Enable "clippy" (a linter) as part of the Rust compilation.
+#
+# Use 'make CLIPPY=1' to enable it.
+ifeq ("$(origin CLIPPY)", "command line")
+  KBUILD_CLIPPY := $(CLIPPY)

[PATCH v8 00/31] Rust support

[Miguel Ojeda]

Rust support

This is the patch series (v8) to add support for Rust as a second
language to the Linux kernel.

If you are interested in following this effort, please join us in
the mailing list at:

rust-for-li...@vger.kernel.org

and take a look at the project itself at:

https://github.com/Rust-for-Linux

As usual, special thanks go to ISRG (Internet Security Research
Group) and Google for their financial support on this endeavor.

Cheers,
Miguel

--

# Rust support

This cover letter explains the major changes and updates done since
the previous ones. For those, please see:

RFC: https://lore.kernel.org/lkml/20210414184604.23473-1-oj...@kernel.org/
v1:  https://lore.kernel.org/lkml/20210704202756.29107-1-oj...@kernel.org/
v2:  https://lore.kernel.org/lkml/20211206140313.5653-1-oj...@kernel.org/
v3:  https://lore.kernel.org/lkml/20220117053349.6804-1-oj...@kernel.org/
v4:  https://lore.kernel.org/lkml/20220212130410.6901-1-oj...@kernel.org/
v5:  https://lore.kernel.org/lkml/20220317181032.15436-1-oj...@kernel.org/
v6:  https://lore.kernel.org/lkml/20220507052451.12890-1-oj...@kernel.org/
v7:  https://lore.kernel.org/lkml/20220523020209.11810-1-oj...@kernel.org/


## Infrastructure updates

There have been several improvements to the overall Rust support:

  - Upgraded toolchain and `alloc` to Rust 1.62.0 from 1.60.0.
Rust 1.61.0 stabilized `feature(const_fn_trait_bound)` that
we are using.

  - Moved bindings into their own crate, `bindings`. This greatly
improves build time when only the `kernel` crate changes (which
previously contained the bindings).

  - Disabled unused `bindgen`'s layout test generation, which makes
rust-analyzer significantly faster to run.

  - `bindgen` can now be detected via the `__BINDGEN__` macro, which
we currently use to workaround an issue with the `btf_type_tag`
attribute.

  - Reimplemented `concat_idents!` (an unstable standard library
macro) as a proc macro, which means we no longer rely on
`feature(concat_idents)`. Furthermore, the proc macro allows
to refer to local variables.

  - Reimplemented `static_assert!` in a more idiomatic way, now that
`core::assert!()` is supported in const contexts.

  - Made `build_error!`' work under `RUST_BUILD_ASSERT_{WARN,ALLOW}`
for modules.

  - Removed `__mulodi4` panicking stub.

  - Added `kernel/configs/rust.config`.

  - Added a (temporary) self-test module for "pure" Rust tests.

  - Changed `.i` macro expanded files to the `.rsi` extension and
clarified that they are not intended to be compilable.

  - Dropped support for compiling the Rust side with a different
optimization level than the C side.

  - The Linux/Tux SVG logo (recently upstreamed) is used for
the generated Rust documentation, instead of the GIF one.
The `COPYING-logo` file is bundled too.

  - Other cleanups, fixes and improvements.


## Abstractions and driver updates

Some of the improvements to the abstractions and example drivers are:

  - Filesystem support (`fs` module), including:

  + `INode` type (which wraps `struct inode`).
  + `DEntry` type (which wraps `struct dentry`).
  + `Filename` type (which wraps `struct filename`).
  + `Registration` type.
  + `Type` and `Context` traits.
  + `SuperBlock` type (which wraps `struct super_block` and takes
advantage of typestates for its initialization).
  + File system parameters support (with a `Value` enum; `Spec*`
and `Constant*` types, `define_fs_params!` macro...).
  + File system flags.
  + `module_fs!` macro to simplify registering kernel modules that
only implement a single file system.
  + A file system sample.

  - Workqueues support (`workqueue` module), including a `Work` type
(which wraps `struct work_struct`), a `Queue` type (which wraps
`struct workqueue_struct`), access to different system queues as
well as macros to simplify usage, e.g.:

spawn_work_item!(workqueue::system(), || pr_info!("Hi!\n"))?;

  - More asynchronous support (`kasync` module), including:

  + Executor support (including `Task` and `Executor` traits, a
`AutoStopHandle` type that automatically stops the executor on
drop, a `spawn_task!` macro that automatically defines a new
lockdep lock class...).

  + A workqueue-based executor, which allows to run tasks on
dedicated or shared thread pools that are managed by existing
C kernel infrastructure, e.g.:

let mut handle = Executor::try_new(workqueue::system())?;

spawn_task!(handle.executor(), async {
pr_info!("First workqueue task\n");
})?;

spawn_task!(handle.executor(), async {
pr_info!("Second workqueue task\n");
})?;

handle.detach();

  + A `yield_now()` function that yields execution of the current
task so that other ones 

RE: [RFC] Remove DECNET support from kernel

[David Laight]

From: Stephen Hemminger
> Sent: 31 July 2022 20:06
> To: net...@vger.kernel.org
> 
> Decnet is an obsolete network protocol that receives more attention
> from kernel janitors than users. It belongs in computer protocol
> history museum not in Linux kernel.
> 
> It has been Orphaned in kernel since 2010.
> And the documentation link on Sourceforge says it is abandoned there.

It was pretty much obsolete when I was writing ethernet drivers
in the early 1990's.
Sort of surprising support ever got into Linux in the first place!

Remember it requires the ethernet MAC address be set to a
locally assigned value that is the machine's 'node number'.

Does this remove some/most/all of the [gs]et_sockopt() calls
where the length is ignored/

David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, 
UK
Registration No: 1397386 (Wales)

Re: [PATCH v3 1/2] lib: generic accessor functions for arch keystore

[Michal Suchánek]

On Mon, Aug 01, 2022 at 03:45:45PM -0400, Nayna wrote:
> 
> On 8/1/22 09:40, Michal Suchánek wrote:
> > Hello,
> > 
> > On Mon, Aug 01, 2022 at 07:34:25AM -0500, gjo...@linux.vnet.ibm.com wrote:
> > > From: Greg Joyce 
> > > 
> > > Generic kernel subsystems may rely on platform specific persistent
> > > KeyStore to store objects containing sensitive key material. In such case,
> > > they need to access architecture specific functions to perform read/write
> > > operations on these variables.
> > > 
> > > Define the generic variable read/write prototypes to be implemented by
> > > architecture specific versions. The default(weak) implementations of
> > > these prototypes return -EOPNOTSUPP unless overridden by architecture
> > > versions.
> > > 
> > > Signed-off-by: Greg Joyce 
> > > ---
> > >   include/linux/arch_vars.h | 23 +++
> > >   lib/Makefile  |  2 +-
> > >   lib/arch_vars.c   | 25 +
> > >   3 files changed, 49 insertions(+), 1 deletion(-)
> > >   create mode 100644 include/linux/arch_vars.h
> > >   create mode 100644 lib/arch_vars.c
> > > 
> > > diff --git a/include/linux/arch_vars.h b/include/linux/arch_vars.h
> > > new file mode 100644
> > > index ..9c280ff9432e
> > > --- /dev/null
> > > +++ b/include/linux/arch_vars.h
> > > @@ -0,0 +1,23 @@
> > > +/* SPDX-License-Identifier: GPL-2.0 */
> > > +/*
> > > + * Platform variable opearations.
> > > + *
> > > + * Copyright (C) 2022 IBM Corporation
> > > + *
> > > + * These are the accessor functions (read/write) for architecture 
> > > specific
> > > + * variables. Specific architectures can provide overrides.
> > > + *
> > > + */
> > > +
> > > +#include 
> > > +
> > > +enum arch_variable_type {
> > > + ARCH_VAR_OPAL_KEY  = 0, /* SED Opal Authentication Key */
> > > + ARCH_VAR_OTHER = 1, /* Other type of variable */
> > > + ARCH_VAR_MAX   = 1, /* Maximum type value */
> > > +};
> > > +
> > > +int arch_read_variable(enum arch_variable_type type, char *varname,
> > > +void *varbuf, u_int *varlen);
> > > +int arch_write_variable(enum arch_variable_type type, char *varname,
> > > + void *varbuf, u_int varlen);
> > > diff --git a/lib/Makefile b/lib/Makefile
> > > index f99bf61f8bbc..b90c4cb0dbbb 100644
> > > --- a/lib/Makefile
> > > +++ b/lib/Makefile
> > > @@ -48,7 +48,7 @@ obj-y += bcd.o sort.o parser.o debug_locks.o random32.o 
> > > \
> > >bsearch.o find_bit.o llist.o memweight.o kfifo.o \
> > >percpu-refcount.o rhashtable.o \
> > >once.o refcount.o usercopy.o errseq.o bucket_locks.o \
> > > -  generic-radix-tree.o
> > > +  generic-radix-tree.o arch_vars.o
> > >   obj-$(CONFIG_STRING_SELFTEST) += test_string.o
> > >   obj-y += string_helpers.o
> > >   obj-$(CONFIG_TEST_STRING_HELPERS) += test-string_helpers.o
> > > diff --git a/lib/arch_vars.c b/lib/arch_vars.c
> > > new file mode 100644
> > > index ..e6f16d7d09c1
> > > --- /dev/null
> > > +++ b/lib/arch_vars.c
> > > @@ -0,0 +1,25 @@
> > > +// SPDX-License-Identifier: GPL-2.0-only
> > > +/*
> > > + * Platform variable operations.
> > > + *
> > > + * Copyright (C) 2022 IBM Corporation
> > > + *
> > > + * These are the accessor functions (read/write) for architecture 
> > > specific
> > > + * variables. Specific architectures can provide overrides.
> > > + *
> > > + */
> > > +
> > > +#include 
> > > +#include 
> > > +
> > > +int __weak arch_read_variable(enum arch_variable_type type, char 
> > > *varname,
> > > +   void *varbuf, u_int *varlen)
> > > +{
> > > + return -EOPNOTSUPP;
> > > +}
> > > +
> > > +int __weak arch_write_variable(enum arch_variable_type type, char 
> > > *varname,
> > > +void *varbuf, u_int varlen)
> > > +{
> > > + return -EOPNOTSUPP;
> > > +}
> > > -- 
> > Doesn't EFI already have some variables?
> > 
> > And even powernv?
> > 
> > Shouldn't this generalize the already existing variables?
> > 
> > Or move to powerpc and at least generalize the powerpc ones?
> 
> Yes, EFI and PowerNV do have variables, but I am not exactly clear about
> your reference to them in this context. What do you mean by generalize
> already existing variables ?
> 
> This interface is actually generalizing calls to access platform specific
> keystores. It is explained in cover letter that this patch is defining
> generic interface and these are default implementations which needs to be
> overridden by arch specific versions.  For PowerVM PLPAR Platform KeyStore,
> the arch specific version is implemented in Patch 2.
For powervm, not powernv.

If it's not generic enough to cover even powerpc-specific keystores does
such generalization even need to exist?
> 
> Access to EFI variables should be implemented by EFI arch specific interface
> and PowerNV will have to do the same if it needs to.

If such generic interface is desirable it should cover the existing
architectures I think. 

Re: [PATCH v3 1/2] lib: generic accessor functions for arch keystore

[Nayna]

On 8/1/22 09:40, Michal Suchánek wrote:

Hello,

On Mon, Aug 01, 2022 at 07:34:25AM -0500, gjo...@linux.vnet.ibm.com wrote:

From: Greg Joyce 

Generic kernel subsystems may rely on platform specific persistent
KeyStore to store objects containing sensitive key material. In such case,
they need to access architecture specific functions to perform read/write
operations on these variables.

Define the generic variable read/write prototypes to be implemented by
architecture specific versions. The default(weak) implementations of
these prototypes return -EOPNOTSUPP unless overridden by architecture
versions.

Signed-off-by: Greg Joyce 
---
  include/linux/arch_vars.h | 23 +++
  lib/Makefile  |  2 +-
  lib/arch_vars.c   | 25 +
  3 files changed, 49 insertions(+), 1 deletion(-)
  create mode 100644 include/linux/arch_vars.h
  create mode 100644 lib/arch_vars.c

diff --git a/include/linux/arch_vars.h b/include/linux/arch_vars.h
new file mode 100644
index ..9c280ff9432e
--- /dev/null
+++ b/include/linux/arch_vars.h
@@ -0,0 +1,23 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Platform variable opearations.
+ *
+ * Copyright (C) 2022 IBM Corporation
+ *
+ * These are the accessor functions (read/write) for architecture specific
+ * variables. Specific architectures can provide overrides.
+ *
+ */
+
+#include 
+
+enum arch_variable_type {
+   ARCH_VAR_OPAL_KEY  = 0, /* SED Opal Authentication Key */
+   ARCH_VAR_OTHER = 1, /* Other type of variable */
+   ARCH_VAR_MAX   = 1, /* Maximum type value */
+};
+
+int arch_read_variable(enum arch_variable_type type, char *varname,
+  void *varbuf, u_int *varlen);
+int arch_write_variable(enum arch_variable_type type, char *varname,
+   void *varbuf, u_int varlen);
diff --git a/lib/Makefile b/lib/Makefile
index f99bf61f8bbc..b90c4cb0dbbb 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -48,7 +48,7 @@ obj-y += bcd.o sort.o parser.o debug_locks.o random32.o \
 bsearch.o find_bit.o llist.o memweight.o kfifo.o \
 percpu-refcount.o rhashtable.o \
 once.o refcount.o usercopy.o errseq.o bucket_locks.o \
-generic-radix-tree.o
+generic-radix-tree.o arch_vars.o
  obj-$(CONFIG_STRING_SELFTEST) += test_string.o
  obj-y += string_helpers.o
  obj-$(CONFIG_TEST_STRING_HELPERS) += test-string_helpers.o
diff --git a/lib/arch_vars.c b/lib/arch_vars.c
new file mode 100644
index ..e6f16d7d09c1
--- /dev/null
+++ b/lib/arch_vars.c
@@ -0,0 +1,25 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Platform variable operations.
+ *
+ * Copyright (C) 2022 IBM Corporation
+ *
+ * These are the accessor functions (read/write) for architecture specific
+ * variables. Specific architectures can provide overrides.
+ *
+ */
+
+#include 
+#include 
+
+int __weak arch_read_variable(enum arch_variable_type type, char *varname,
+ void *varbuf, u_int *varlen)
+{
+   return -EOPNOTSUPP;
+}
+
+int __weak arch_write_variable(enum arch_variable_type type, char *varname,
+  void *varbuf, u_int varlen)
+{
+   return -EOPNOTSUPP;
+}
--

Doesn't EFI already have some variables?

And even powernv?

Shouldn't this generalize the already existing variables?

Or move to powerpc and at least generalize the powerpc ones?


Yes, EFI and PowerNV do have variables, but I am not exactly clear about 
your reference to them in this context. What do you mean by generalize 
already existing variables ?


This interface is actually generalizing calls to access platform 
specific keystores. It is explained in cover letter that this patch is 
defining generic interface and these are default implementations which 
needs to be overridden by arch specific versions.  For PowerVM PLPAR 
Platform KeyStore, the arch specific version is implemented in Patch 2.


Access to EFI variables should be implemented by EFI arch specific 
interface and PowerNV will have to do the same if it needs to.


Hope it helps.

Thanks & Regards,

    - Nayna

[PATCH AUTOSEL 5.10 2/7] powerpc/64s: Disable stack variable initialisation for prom_init

[Sasha Levin]

From: Michael Ellerman 

[ Upstream commit be640317a1d0b9cf42fedb2debc2887a7cfa38de ]

With GCC 12 allmodconfig prom_init fails to build:

  Error: External symbol 'memset' referenced from prom_init.c
  make[2]: *** [arch/powerpc/kernel/Makefile:204: 
arch/powerpc/kernel/prom_init_check] Error 1

The allmodconfig build enables KASAN, so all calls to memset in
prom_init should be converted to __memset by the #ifdefs in
asm/string.h, because prom_init must use the non-KASAN instrumented
versions.

The build failure happens because there's a call to memset that hasn't
been caught by the pre-processor and converted to __memset. Typically
that's because it's a memset generated by the compiler itself, and that
is the case here.

With GCC 12, allmodconfig enables CONFIG_INIT_STACK_ALL_PATTERN, which
causes the compiler to emit memset calls to initialise on-stack
variables with a pattern.

Because prom_init is non-user-facing boot-time only code, as a
workaround just disable stack variable initialisation to unbreak the
build.

Reported-by: Sudip Mukherjee 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20220718134418.354114-1-...@ellerman.id.au
Signed-off-by: Sasha Levin 
---
 arch/powerpc/kernel/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 376104c166fc..db2bdc4cec64 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -20,6 +20,7 @@ CFLAGS_prom.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
 CFLAGS_prom_init.o += -fno-stack-protector
 CFLAGS_prom_init.o += -DDISABLE_BRANCH_PROFILING
 CFLAGS_prom_init.o += -ffreestanding
+CFLAGS_prom_init.o += $(call cc-option, -ftrivial-auto-var-init=uninitialized)
 
 ifdef CONFIG_FUNCTION_TRACER
 # Do not trace early boot code
-- 
2.35.1

[PATCH AUTOSEL 5.15 3/8] powerpc/64s: Disable stack variable initialisation for prom_init

[Sasha Levin]

From: Michael Ellerman 

[ Upstream commit be640317a1d0b9cf42fedb2debc2887a7cfa38de ]

With GCC 12 allmodconfig prom_init fails to build:

  Error: External symbol 'memset' referenced from prom_init.c
  make[2]: *** [arch/powerpc/kernel/Makefile:204: 
arch/powerpc/kernel/prom_init_check] Error 1

The allmodconfig build enables KASAN, so all calls to memset in
prom_init should be converted to __memset by the #ifdefs in
asm/string.h, because prom_init must use the non-KASAN instrumented
versions.

The build failure happens because there's a call to memset that hasn't
been caught by the pre-processor and converted to __memset. Typically
that's because it's a memset generated by the compiler itself, and that
is the case here.

With GCC 12, allmodconfig enables CONFIG_INIT_STACK_ALL_PATTERN, which
causes the compiler to emit memset calls to initialise on-stack
variables with a pattern.

Because prom_init is non-user-facing boot-time only code, as a
workaround just disable stack variable initialisation to unbreak the
build.

Reported-by: Sudip Mukherjee 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20220718134418.354114-1-...@ellerman.id.au
Signed-off-by: Sasha Levin 
---
 arch/powerpc/kernel/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index b1b23b4d56ba..ed91d5b9ffc6 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -20,6 +20,7 @@ CFLAGS_prom.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
 CFLAGS_prom_init.o += -fno-stack-protector
 CFLAGS_prom_init.o += -DDISABLE_BRANCH_PROFILING
 CFLAGS_prom_init.o += -ffreestanding
+CFLAGS_prom_init.o += $(call cc-option, -ftrivial-auto-var-init=uninitialized)
 
 ifdef CONFIG_FUNCTION_TRACER
 # Do not trace early boot code
-- 
2.35.1

[PATCH AUTOSEL 5.18 04/10] powerpc/64s: Disable stack variable initialisation for prom_init

[Sasha Levin]

From: Michael Ellerman 

[ Upstream commit be640317a1d0b9cf42fedb2debc2887a7cfa38de ]

With GCC 12 allmodconfig prom_init fails to build:

  Error: External symbol 'memset' referenced from prom_init.c
  make[2]: *** [arch/powerpc/kernel/Makefile:204: 
arch/powerpc/kernel/prom_init_check] Error 1

The allmodconfig build enables KASAN, so all calls to memset in
prom_init should be converted to __memset by the #ifdefs in
asm/string.h, because prom_init must use the non-KASAN instrumented
versions.

The build failure happens because there's a call to memset that hasn't
been caught by the pre-processor and converted to __memset. Typically
that's because it's a memset generated by the compiler itself, and that
is the case here.

With GCC 12, allmodconfig enables CONFIG_INIT_STACK_ALL_PATTERN, which
causes the compiler to emit memset calls to initialise on-stack
variables with a pattern.

Because prom_init is non-user-facing boot-time only code, as a
workaround just disable stack variable initialisation to unbreak the
build.

Reported-by: Sudip Mukherjee 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20220718134418.354114-1-...@ellerman.id.au
Signed-off-by: Sasha Levin 
---
 arch/powerpc/kernel/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 4ddd161aef32..63c384c3e6d4 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -20,6 +20,7 @@ CFLAGS_prom.o += $(DISABLE_LATENT_ENTROPY_PLUGIN)
 CFLAGS_prom_init.o += -fno-stack-protector
 CFLAGS_prom_init.o += -DDISABLE_BRANCH_PROFILING
 CFLAGS_prom_init.o += -ffreestanding
+CFLAGS_prom_init.o += $(call cc-option, -ftrivial-auto-var-init=uninitialized)
 
 ifdef CONFIG_FUNCTION_TRACER
 # Do not trace early boot code
-- 
2.35.1

Re: [PATCH] powerpc/pseries: add lparctl driver for platform-specific functions

[Laurent Dufour]

Le 30/07/2022 à 02:04, Nathan Lynch a écrit :
> This adds a chardev+ioctl-based interface for user space to access pseries
> platform-specific functions which don't easily fit elsewhere.
> 
> The immediate motivation is to unbreak librtas[1] with kernel lockdown
> enabled. librtas provides a thin root-only user-space API, allowing nearly
> direct access to RTAS functions. Since its inception, some of librtas's
> APIs have used /dev/mem to allocate buffers that are addressable by RTAS
> for use with the powerpc-specific rtas() syscall. This design likely would
> not be our first choice today, but it has served adequately for about two
> decades without much change, and librtas has a non-negligible number of
> existing users, including powerpc-utils, ppc64-diag, lsvpd, lscpu
> (util-linux), and several non-OSS programs. With lockdown enabled, /dev/mem
> access is prohibited, preventing communication with the management console
> and breaking associated functions such as DLPAR and partition migration.
> 
> So the task is to provide new lockdown-compatible interfaces for librtas to
> prefer over the legacy /dev/mem+sys_rtas(), allowing it to maintain its own
> user-facing ABIs as much as possible. This means that we make different
> interface choices than we would were we writing everything from scratch. In
> the ioctl commands added here, we do not map RTAS error statuses to Linux
> errno values, because the existing users of librtas's system parameter APIs
> expect the RTAS status codes. Instead, the ioctl succeeds if the kernel
> manages to call the RTAS function at all, and passes the RTAS status back
> to user space in the argument buffer.
> 
> Add the ability to retrieve and change system parameters as defined by
> PAPR. Along with proposed implementation changes to librtas[2], this
> effectively fixes librtas's rtas_get_sysparm() and rtas_set_sysparm() APIs
> for existing users with lockdown. This is enough to get HMC communication
> working via the proprietary RSCT stack, enabling LPM, processor DLPAR,
> memory DLPAR, and various other use cases.
> 
> While this starts with RTAS-implemented functions, there's no reason it
> couldn't host facilities that rely on hcalls or other PAPR-specified
> interfaces. It could be an alternative to adding more key=value lines to
> /proc/powrpc/lparcfg. Hence the generic name 'lparctl'.
> 
> Utilities tested (ppc64le kernel and user space):
> * ppc64_cpu --run-mode (powerpc-utils, gets/sets processor diag run mode)
> * serv_config (powerpc-utils, gets/sets various system and LPAR policies)
> * lscpu (util-linux, retrieves processor topology)
> * RSCT (proprietary, retrieves HMC connection details)
> 
> Future work to unbreak more librtas APIs may include:
> * VPD retrieval via ibm,get-vpd
> * RTAS error injection
> * indicator query/manipulation for diagnostics
> 
> [1] https://github.com/ibm-power-utilities/librtas
> [2] https://github.com/ibm-power-utilities/librtas/pull/26
> 
> Signed-off-by: Nathan Lynch 
> ---
>  .../userspace-api/ioctl/ioctl-number.rst  |   1 +
>  arch/powerpc/include/uapi/asm/lparctl.h   |  63 +++
>  arch/powerpc/platforms/pseries/Makefile   |   2 +-
>  arch/powerpc/platforms/pseries/lparctl.c  | 171 ++
>  4 files changed, 236 insertions(+), 1 deletion(-)
>  create mode 100644 arch/powerpc/include/uapi/asm/lparctl.h
>  create mode 100644 arch/powerpc/platforms/pseries/lparctl.c
> 
> diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst 
> b/Documentation/userspace-api/ioctl/ioctl-number.rst
> index fcab013e47c9..029de1b7ebdb 100644
> --- a/Documentation/userspace-api/ioctl/ioctl-number.rst
> +++ b/Documentation/userspace-api/ioctl/ioctl-number.rst
> @@ -349,6 +349,7 @@ Code  Seq#Include File
>Comments
>   
> 
>  0xB1  00-1F  PPPoX
>   
> 
> +0xB2  01-02  arch/powerpc/include/uapi/asm/lparctl.h 
> powerpc/pseries lparctl API
>  0xB3  00 linux/mmc/ioctl.h
>  0xB4  00-0F  linux/gpio.h
> 
>  0xB5  00-0F  uapi/linux/rpmsg.h  
> 
> diff --git a/arch/powerpc/include/uapi/asm/lparctl.h 
> b/arch/powerpc/include/uapi/asm/lparctl.h
> new file mode 100644
> index ..42e1ee5fe3c8
> --- /dev/null
> +++ b/arch/powerpc/include/uapi/asm/lparctl.h
> @@ -0,0 +1,63 @@
> +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
> +#ifndef POWERPC_UAPI_LPARCTL_H
> +#define POWERPC_UAPI_LPARCTL_H
> +
> +#include 
> +#include 
> +
> +#define LPARCTL_IOCTL_BASE 0xb2
> +
> +#define LPARCTL_IO(nr) _IO(LPARCTL_IOCTL_BASE, nr)
> 

Re: [PATCH v3] random: handle archrandom with multiple longs

[Harald Freudenberger]

On 2022-07-19 15:02, Jason A. Donenfeld wrote:
The archrandom interface was originally designed for x86, which 
supplies

RDRAND/RDSEED for receiving random words into registers, resulting in
one function to generate an int and another to generate a long. 
However,

other architectures don't follow this.

On arm64, the SMCCC TRNG interface can return between 1 and 3 longs. On
s390, the CPACF TRNG interface can return arbitrary amounts, with 32
longs having the same cost as one. On UML, the os_getrandom() interface
can return arbitrary amounts.

So change the api signature to take a "max_longs" parameter designating
the maximum number of longs requested, and then return the number of
longs generated.

Since callers need to check this return value and loop anyway, each 
arch
implementation does not bother implementing its own loop to try again 
to

fill the maximum number of longs. Additionally, all existing callers
pass in a constant max_longs parameter. Taken together, these two 
things

mean that the codegen doesn't really change much for one-word-at-a-time
platforms, while performance is greatly improved on platforms such as
s390.

Cc: Will Deacon 
Cc: Alexander Gordeev 
Cc: Thomas Gleixner 
Cc: H. Peter Anvin 
Cc: Catalin Marinas 
Cc: Borislav Petkov 
Cc: Heiko Carstens 
Cc: Johannes Berg 
Cc: Mark Rutland 
Cc: Harald Freudenberger 
Acked-by: Michael Ellerman 
Signed-off-by: Jason A. Donenfeld 
---
 arch/arm64/include/asm/archrandom.h   | 102 --
 arch/arm64/kernel/kaslr.c |   2 +-
 arch/powerpc/include/asm/archrandom.h |  30 ++--
 arch/powerpc/kvm/book3s_hv.c  |   2 +-
 arch/s390/include/asm/archrandom.h|  29 ++--
 arch/um/include/asm/archrandom.h  |  21 ++
 arch/x86/include/asm/archrandom.h |  41 +--
 arch/x86/kernel/espfix_64.c   |   2 +-
 drivers/char/random.c |  45 
 include/asm-generic/archrandom.h  |  18 +
 include/linux/random.h|  12 +--
 11 files changed, 116 insertions(+), 188 deletions(-)

diff --git a/arch/arm64/include/asm/archrandom.h
b/arch/arm64/include/asm/archrandom.h
index c3b9fa56af67..109e2a4454be 100644
--- a/arch/arm64/include/asm/archrandom.h
+++ b/arch/arm64/include/asm/archrandom.h
@@ -58,7 +58,7 @@ static inline bool __arm64_rndrrs(unsigned long *v)
return ok;
 }

-static inline bool __must_check arch_get_random_long(unsigned long *v)
+static inline size_t __must_check arch_get_random_longs(unsigned long
*v, size_t max_longs)
 {
/*
 * Only support the generic interface after we have detected
@@ -66,27 +66,15 @@ static inline bool __must_check
arch_get_random_long(unsigned long *v)
 * cpufeature code and with potential scheduling between CPUs
 * with and without the feature.
 */
-   if (cpus_have_const_cap(ARM64_HAS_RNG) && __arm64_rndr(v))
-   return true;
-   return false;
+	if (max_longs && cpus_have_const_cap(ARM64_HAS_RNG) && 
__arm64_rndr(v))

+   return 1;
+   return 0;
 }

-static inline bool __must_check arch_get_random_int(unsigned int *v)
+static inline size_t __must_check arch_get_random_seed_longs(unsigned
long *v, size_t max_longs)
 {
-   if (cpus_have_const_cap(ARM64_HAS_RNG)) {
-   unsigned long val;
-
-   if (__arm64_rndr()) {
-   *v = val;
-   return true;
-   }
-   }
-   return false;
-}
-
-static inline bool __must_check arch_get_random_seed_long(unsigned 
long *v)

-{
-   struct arm_smccc_res res;
+   if (!max_longs)
+   return 0;

/*
 * We prefer the SMCCC call, since its semantics (return actual
@@ -95,10 +83,23 @@ static inline bool __must_check
arch_get_random_seed_long(unsigned long *v)
 * (the output of a pseudo RNG freshly seeded by a TRNG).
 */
if (smccc_trng_available) {
-   arm_smccc_1_1_invoke(ARM_SMCCC_TRNG_RND64, 64, );
+   struct arm_smccc_res res;
+
+   max_longs = min_t(size_t, 3, max_longs);
+   arm_smccc_1_1_invoke(ARM_SMCCC_TRNG_RND64, max_longs * 64, 
);
if ((int)res.a0 >= 0) {
-   *v = res.a3;
-   return true;
+   switch (max_longs) {
+   case 3:
+   *v++ = res.a1;
+   fallthrough;
+   case 2:
+   *v++ = res.a2;
+   fallthrough;
+   case 1:
+   *v++ = res.a3;
+   break;
+   }
+   return max_longs;
}
}

@@ -108,32 +109,9 @@ static inline bool __must_check
arch_get_random_seed_long(unsigned long *v)
 * enough to implement this API if no other entropy source 

Re: [PATCH v3 1/2] lib: generic accessor functions for arch keystore

[Michal Suchánek]

Hello,

On Mon, Aug 01, 2022 at 07:34:25AM -0500, gjo...@linux.vnet.ibm.com wrote:
> From: Greg Joyce 
> 
> Generic kernel subsystems may rely on platform specific persistent
> KeyStore to store objects containing sensitive key material. In such case,
> they need to access architecture specific functions to perform read/write
> operations on these variables.
> 
> Define the generic variable read/write prototypes to be implemented by
> architecture specific versions. The default(weak) implementations of
> these prototypes return -EOPNOTSUPP unless overridden by architecture
> versions.
> 
> Signed-off-by: Greg Joyce 
> ---
>  include/linux/arch_vars.h | 23 +++
>  lib/Makefile  |  2 +-
>  lib/arch_vars.c   | 25 +
>  3 files changed, 49 insertions(+), 1 deletion(-)
>  create mode 100644 include/linux/arch_vars.h
>  create mode 100644 lib/arch_vars.c
> 
> diff --git a/include/linux/arch_vars.h b/include/linux/arch_vars.h
> new file mode 100644
> index ..9c280ff9432e
> --- /dev/null
> +++ b/include/linux/arch_vars.h
> @@ -0,0 +1,23 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Platform variable opearations.
> + *
> + * Copyright (C) 2022 IBM Corporation
> + *
> + * These are the accessor functions (read/write) for architecture specific
> + * variables. Specific architectures can provide overrides.
> + *
> + */
> +
> +#include 
> +
> +enum arch_variable_type {
> + ARCH_VAR_OPAL_KEY  = 0, /* SED Opal Authentication Key */
> + ARCH_VAR_OTHER = 1, /* Other type of variable */
> + ARCH_VAR_MAX   = 1, /* Maximum type value */
> +};
> +
> +int arch_read_variable(enum arch_variable_type type, char *varname,
> +void *varbuf, u_int *varlen);
> +int arch_write_variable(enum arch_variable_type type, char *varname,
> + void *varbuf, u_int varlen);
> diff --git a/lib/Makefile b/lib/Makefile
> index f99bf61f8bbc..b90c4cb0dbbb 100644
> --- a/lib/Makefile
> +++ b/lib/Makefile
> @@ -48,7 +48,7 @@ obj-y += bcd.o sort.o parser.o debug_locks.o random32.o \
>bsearch.o find_bit.o llist.o memweight.o kfifo.o \
>percpu-refcount.o rhashtable.o \
>once.o refcount.o usercopy.o errseq.o bucket_locks.o \
> -  generic-radix-tree.o
> +  generic-radix-tree.o arch_vars.o
>  obj-$(CONFIG_STRING_SELFTEST) += test_string.o
>  obj-y += string_helpers.o
>  obj-$(CONFIG_TEST_STRING_HELPERS) += test-string_helpers.o
> diff --git a/lib/arch_vars.c b/lib/arch_vars.c
> new file mode 100644
> index ..e6f16d7d09c1
> --- /dev/null
> +++ b/lib/arch_vars.c
> @@ -0,0 +1,25 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Platform variable operations.
> + *
> + * Copyright (C) 2022 IBM Corporation
> + *
> + * These are the accessor functions (read/write) for architecture specific
> + * variables. Specific architectures can provide overrides.
> + *
> + */
> +
> +#include 
> +#include 
> +
> +int __weak arch_read_variable(enum arch_variable_type type, char *varname,
> +   void *varbuf, u_int *varlen)
> +{
> + return -EOPNOTSUPP;
> +}
> +
> +int __weak arch_write_variable(enum arch_variable_type type, char *varname,
> +void *varbuf, u_int varlen)
> +{
> + return -EOPNOTSUPP;
> +}
> -- 

Doesn't EFI already have some variables?

And even powernv?

Shouldn't this generalize the already existing variables?

Or move to powerpc and at least generalize the powerpc ones?

Thanks

Michal

[PATCH v3 2/2] powerpc/pseries: Override lib/arch_vars.c functions

[gjoyce]

From: Greg Joyce 

Self Encrypting Drives(SED) make use of POWER LPAR Platform KeyStore
for storing its variables. Thus the block subsystem needs to access
PowerPC specific functions to read/write objects in PLPKS.

Override the default implementations in lib/arch_vars.c file with
PowerPC specific versions.

Signed-off-by: Greg Joyce 
---
 arch/powerpc/platforms/pseries/Makefile   |   1 +
 .../platforms/pseries/plpks_arch_ops.c| 167 ++
 2 files changed, 168 insertions(+)
 create mode 100644 arch/powerpc/platforms/pseries/plpks_arch_ops.c

diff --git a/arch/powerpc/platforms/pseries/Makefile 
b/arch/powerpc/platforms/pseries/Makefile
index 14e143b946a3..3a545422eae5 100644
--- a/arch/powerpc/platforms/pseries/Makefile
+++ b/arch/powerpc/platforms/pseries/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_PPC_SPLPAR)  += vphn.o
 obj-$(CONFIG_PPC_SVM)  += svm.o
 obj-$(CONFIG_FA_DUMP)  += rtas-fadump.o
 obj-$(CONFIG_PSERIES_PLPKS) += plpks.o
+obj-$(CONFIG_PSERIES_PLPKS) += plpks_arch_ops.o
 
 obj-$(CONFIG_SUSPEND)  += suspend.o
 obj-$(CONFIG_PPC_VAS)  += vas.o vas-sysfs.o
diff --git a/arch/powerpc/platforms/pseries/plpks_arch_ops.c 
b/arch/powerpc/platforms/pseries/plpks_arch_ops.c
new file mode 100644
index ..fdea3322f696
--- /dev/null
+++ b/arch/powerpc/platforms/pseries/plpks_arch_ops.c
@@ -0,0 +1,167 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * POWER Platform arch specific code for SED
+ * Copyright (C) 2022 IBM Corporation
+ *
+ * Define operations for generic kernel subsystems to read/write keys
+ * from POWER LPAR Platform KeyStore(PLPKS).
+ *
+ * List of subsystems/usecase using PLPKS:
+ * - Self Encrypting Drives(SED)
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "plpks.h"
+
+/*
+ * variable structure that contains all SED data
+ */
+struct plpks_sed_object_data {
+   u_char version;
+   u_char pad1[7];
+   u_long authority;
+   u_long range;
+   u_int  key_len;
+   u_char key[32];
+};
+
+/*
+ * ext_type values
+ * 00no extension exists
+ * 01-1F common
+ * 20-3F AIX
+ * 40-5F Linux
+ * 60-7F IBMi
+ */
+
+/*
+ * This extension is optional for version 1 sed_object_data
+ */
+struct sed_object_extension {
+   u8 ext_type;
+   u8 rsvd[3];
+   u8 ext_data[64];
+};
+
+#define PKS_SED_OBJECT_DATA_V1  1
+#define PKS_SED_MANGLED_LABEL   "/default/pri"
+#define PLPKS_SED_COMPONENT "sed-opal"
+
+#define PLPKS_ARCHVAR_POLICYWORLDREADABLE
+#define PLPKS_ARCHVAR_OS_COMMON 4
+
+/*
+ * Read the variable data from PKS given the label
+ */
+int arch_read_variable(enum arch_variable_type type, char *varname,
+  void *varbuf, u_int *varlen)
+{
+   struct plpks_var var;
+   struct plpks_sed_object_data *data;
+   u_int offset = 0;
+   char *buf = (char *)varbuf;
+   int ret;
+
+   var.name = varname;
+   var.namelen = strlen(varname);
+   var.policy = PLPKS_ARCHVAR_POLICY;
+   var.os = PLPKS_ARCHVAR_OS_COMMON;
+   var.data = NULL;
+   var.datalen = 0;
+
+   switch (type) {
+   case ARCH_VAR_OPAL_KEY:
+   var.component = PLPKS_SED_COMPONENT;
+#ifdef OPAL_AUTH_KEY
+   if (strcmp(OPAL_AUTH_KEY, varname) == 0) {
+   var.name = PKS_SED_MANGLED_LABEL;
+   var.namelen = strlen(varname);
+   }
+#endif
+   offset = offsetof(struct plpks_sed_object_data, key);
+   break;
+   case ARCH_VAR_OTHER:
+   var.component = "";
+   break;
+   }
+
+   ret = plpks_read_os_var();
+   if (ret != 0)
+   return ret;
+
+   if (offset > var.datalen)
+   offset = 0;
+
+   switch (type) {
+   case ARCH_VAR_OPAL_KEY:
+   data = (struct plpks_sed_object_data *)var.data;
+   *varlen = data->key_len;
+   break;
+   case ARCH_VAR_OTHER:
+   *varlen = var.datalen;
+   break;
+   }
+
+   if (var.data) {
+   memcpy(varbuf, var.data + offset, var.datalen - offset);
+   buf[*varlen] = '\0';
+   kfree(var.data);
+   }
+
+   return 0;
+}
+
+/*
+ * Write the variable data to PKS given the label
+ */
+int arch_write_variable(enum arch_variable_type type, char *varname,
+   void *varbuf, u_int varlen)
+{
+   struct plpks_var var;
+   struct plpks_sed_object_data data;
+   struct plpks_var_name vname;
+
+   var.name = varname;
+   var.namelen = strlen(varname);
+   var.policy = PLPKS_ARCHVAR_POLICY;
+   var.os = PLPKS_ARCHVAR_OS_COMMON;
+   var.datalen = varlen;
+   var.data = varbuf;
+
+   switch (type) {
+   case ARCH_VAR_OPAL_KEY:
+   var.component = PLPKS_SED_COMPONENT;
+#ifdef 

[PATCH v3 1/2] lib: generic accessor functions for arch keystore

[gjoyce]

From: Greg Joyce 

Generic kernel subsystems may rely on platform specific persistent
KeyStore to store objects containing sensitive key material. In such case,
they need to access architecture specific functions to perform read/write
operations on these variables.

Define the generic variable read/write prototypes to be implemented by
architecture specific versions. The default(weak) implementations of
these prototypes return -EOPNOTSUPP unless overridden by architecture
versions.

Signed-off-by: Greg Joyce 
---
 include/linux/arch_vars.h | 23 +++
 lib/Makefile  |  2 +-
 lib/arch_vars.c   | 25 +
 3 files changed, 49 insertions(+), 1 deletion(-)
 create mode 100644 include/linux/arch_vars.h
 create mode 100644 lib/arch_vars.c

diff --git a/include/linux/arch_vars.h b/include/linux/arch_vars.h
new file mode 100644
index ..9c280ff9432e
--- /dev/null
+++ b/include/linux/arch_vars.h
@@ -0,0 +1,23 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Platform variable opearations.
+ *
+ * Copyright (C) 2022 IBM Corporation
+ *
+ * These are the accessor functions (read/write) for architecture specific
+ * variables. Specific architectures can provide overrides.
+ *
+ */
+
+#include 
+
+enum arch_variable_type {
+   ARCH_VAR_OPAL_KEY  = 0, /* SED Opal Authentication Key */
+   ARCH_VAR_OTHER = 1, /* Other type of variable */
+   ARCH_VAR_MAX   = 1, /* Maximum type value */
+};
+
+int arch_read_variable(enum arch_variable_type type, char *varname,
+  void *varbuf, u_int *varlen);
+int arch_write_variable(enum arch_variable_type type, char *varname,
+   void *varbuf, u_int varlen);
diff --git a/lib/Makefile b/lib/Makefile
index f99bf61f8bbc..b90c4cb0dbbb 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -48,7 +48,7 @@ obj-y += bcd.o sort.o parser.o debug_locks.o random32.o \
 bsearch.o find_bit.o llist.o memweight.o kfifo.o \
 percpu-refcount.o rhashtable.o \
 once.o refcount.o usercopy.o errseq.o bucket_locks.o \
-generic-radix-tree.o
+generic-radix-tree.o arch_vars.o
 obj-$(CONFIG_STRING_SELFTEST) += test_string.o
 obj-y += string_helpers.o
 obj-$(CONFIG_TEST_STRING_HELPERS) += test-string_helpers.o
diff --git a/lib/arch_vars.c b/lib/arch_vars.c
new file mode 100644
index ..e6f16d7d09c1
--- /dev/null
+++ b/lib/arch_vars.c
@@ -0,0 +1,25 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Platform variable operations.
+ *
+ * Copyright (C) 2022 IBM Corporation
+ *
+ * These are the accessor functions (read/write) for architecture specific
+ * variables. Specific architectures can provide overrides.
+ *
+ */
+
+#include 
+#include 
+
+int __weak arch_read_variable(enum arch_variable_type type, char *varname,
+ void *varbuf, u_int *varlen)
+{
+   return -EOPNOTSUPP;
+}
+
+int __weak arch_write_variable(enum arch_variable_type type, char *varname,
+  void *varbuf, u_int varlen)
+{
+   return -EOPNOTSUPP;
+}
-- 
2.27.0

[PATCH v3 0/2] generic and PowerPC accessor functions for arch keystore

[gjoyce]

From: Greg Joyce 

Architectural neutral functions have been defined for accessing
architecture specific variable store. The neutral functions are
defined as weak so that they may be superseded by platform
specific versions.

PowerPC/pseries versions of these functions provide read/write access
to the non-volatile PLPKS data store.

This functionality allows kernel code such as the block SED opal
driver to store authentication keys in a secure permanent store.

Greg Joyce (2):
  lib: define generic accessor functions for arch specific keystore
  powerpc/pseries: Override lib/arch_vars.c functions

 arch/powerpc/platforms/pseries/Makefile   |   1 +
 .../platforms/pseries/plpks_arch_ops.c| 167 ++
 include/linux/arch_vars.h |  23 +++
 lib/Makefile  |   2 +-
 lib/arch_vars.c   |  25 +++
 5 files changed, 217 insertions(+), 1 deletion(-)
 create mode 100644 arch/powerpc/platforms/pseries/plpks_arch_ops.c
 create mode 100644 include/linux/arch_vars.h
 create mode 100644 lib/arch_vars.c


Signed-off-by: Greg Joyce 
base-commit: ff6992735ade75aae3e35d16b17da1008d753d28
-- 
2.27.0

Re: [PATCH 2/2] powerpc/64: poison __per_cpu_offset to catch use-before-init

[Michael Ellerman]

Nicholas Piggin  writes:
> If the boot CPU tries to access per-cpu data of other CPUs before
> per cpu areas are set up, it will unexpectedly use offset 0.
>
> Try to catch such accesses by poisoning the __per_cpu_offset array.

I wasn't sure about this.

On bare metal it's just an instant checkstop which is very user hostile.

I worry it's just going to cause unusual configurations/options to crash
for folks, like eg. booting with page_poison=1 did a while back.

Can we put it behind a debug option? Maybe CONFIG_DEBUG_VM ?

cheers

[PATCH] selftests/powerpc: Avoid GCC 12 uninitialised variable warning

[Michael Ellerman]

GCC 12 thinks that `actual` might be used uninitialised. It's not, the
use is guarded by `bad_mmcr2` which is only set to true at the same
point where `actual` is initialised.

  cycles_with_mmcr2_test.c: In function ‘cycles_with_mmcr2’:
  cycles_with_mmcr2_test.c:81:17: error: ‘actual’ may be used uninitialized 
[-Werror=maybe-uninitialized]
 81 | printf("Bad MMCR2 value seen is 0x%lx\n", actual);

Silence the warning by initialising `actual` to zero.

Signed-off-by: Michael Ellerman 
---
 tools/testing/selftests/powerpc/pmu/ebb/cycles_with_mmcr2_test.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/testing/selftests/powerpc/pmu/ebb/cycles_with_mmcr2_test.c 
b/tools/testing/selftests/powerpc/pmu/ebb/cycles_with_mmcr2_test.c
index 4b45a2e70f62..fc32187d483d 100644
--- a/tools/testing/selftests/powerpc/pmu/ebb/cycles_with_mmcr2_test.c
+++ b/tools/testing/selftests/powerpc/pmu/ebb/cycles_with_mmcr2_test.c
@@ -50,6 +50,7 @@ int cycles_with_mmcr2(void)
expected[1] = MMCR2_EXPECTED_2;
i = 0;
bad_mmcr2 = false;
+   actual = 0;
 
/* Make sure we loop until we take at least one EBB */
while ((ebb_state.stats.ebb_count < 20 && !bad_mmcr2) ||
-- 
2.35.3

Re: [PATCH v2 02/14] powerpc: Remove direct call to personality syscall handler

[Andrew Donnellan]

On Mon, 2022-07-25 at 16:25 +1000, Rohan McLure wrote:
> Syscall handlers should not be invoked internally by their symbol
> names,
> as these symbols defined by the architecture-defined SYSCALL_DEFINE
> macro. Fortunately, in the case of ppc64_personality, its call to
> sys_personality can be replaced with an invocation to the
> equivalent ksys_personality inline helper in .
> 
> Signed-off-by: Rohan McLure 

Reviewed-by: Andrew Donnellan 

> ---
> V1 -> V2: Use inline helper to deduplicate bodies in compat/regular
> implementations.
> ---
>  arch/powerpc/kernel/syscalls.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/kernel/syscalls.c
> b/arch/powerpc/kernel/syscalls.c
> index ca20083dd0ae..22755502afc0 100644
> --- a/arch/powerpc/kernel/syscalls.c
> +++ b/arch/powerpc/kernel/syscalls.c
> @@ -89,7 +89,7 @@ static inline long do_ppc64_personality(unsigned
> long personality)
> if (personality(current->personality) == PER_LINUX32
>     && personality(personality) == PER_LINUX)
> personality = (personality & ~PER_MASK) |
> PER_LINUX32;
> -   ret = sys_personality(personality);
> +   ret = ksys_personality(personality);
> if (personality(ret) == PER_LINUX32)
> ret = (ret & ~PER_MASK) | PER_LINUX;
> return ret;

Re: [RFC] Remove DECNET support from kernel

[David Ahern]

On 7/31/22 1:06 PM, Stephen Hemminger wrote:
> Decnet is an obsolete network protocol that receives more attention
> from kernel janitors than users. It belongs in computer protocol
> history museum not in Linux kernel.
> 
> It has been Orphaned in kernel since 2010.
> And the documentation link on Sourceforge says it is abandoned there.
> 
> Leave the UAPI alone to keep userspace programs compiling.
> 
> Signed-off-by: Stephen Hemminger 
> ---

Acked-by: David Ahern 

Re: [PATCH] powerpc/85xx: P2020: Add law_trgt_if property to PCIe DT nodes

[Pali Rohár]

On Monday 01 August 2022 13:38:32 Michael Ellerman wrote:
> Rob Herring  writes:
> > On Fri, Jul 29, 2022 at 7:17 AM Michael Ellerman
> >  wrote:
> >>
> >> On Wed, 4 May 2022 20:08:22 +0200, Pali Rohár wrote:
> >> > DT law_trgt_if property defines Local Access Window Target Interface.
> >> >
> >> > Local Access Window Target Interface is used for identifying individual
> >> > peripheral and mapping its memory to CPU. Interface id is defined by
> >> > hardware itself.
> >> >
> >> > U-Boot uses law_trgt_if DT property in PCIe nodes for configuring memory
> >> > mapping of individual PCIe controllers.
> >> >
> >> > [...]
> >>
> >> Applied to powerpc/next.
> >>
> >> [1/1] powerpc/85xx: P2020: Add law_trgt_if property to PCIe DT nodes
> >>   
> >> https://git.kernel.org/powerpc/c/1f00b5ab992c122c51bc37662b3b4df5963462f3
> >
> > Why? Minimally, it needs a vendor prefix and s/_/-/ as I commented.
> 
> OK. I misread your "maybe that's fine" as approval.
> 
> Pali can you send a fixup patch please?
> 
> cheers

No I cannot. This is how this property is used by bootloaders for at
least 10 years. There are underlines (not hyphens) and there is no
vendor prefix.

Re: [PATCH linux-next] macintosh:adb:recordmcount:use !E in conditional statements

[Michael Ellerman]

cgel@gmail.com writes:
> From: ye xingchen 
>
> Use !E to replace the type of x == 0. This change is just to 
> simplify the code, no actual functional changes.
>
> Reported-by: Zeal Robot 
> Signed-off-by: ye xingchen 
> ---
>  drivers/macintosh/adb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

The subject is wrong, why does it mention recordmcount?

But in general this is very old code which is best left alone unless
there's an actual bug, it doesn't need these sort of style refactorings
done to it IMO.

cheers

> diff --git a/drivers/macintosh/adb.c b/drivers/macintosh/adb.c
> index 1bbb9ca08d40..368ab25db234 100644
> --- a/drivers/macintosh/adb.c
> +++ b/drivers/macintosh/adb.c
> @@ -673,7 +673,7 @@ static int adb_open(struct inode *inode, struct file 
> *file)
>   goto out;
>   }
>   state = kmalloc(sizeof(struct adbdev_state), GFP_KERNEL);
> - if (state == 0) {
> + if (!state) {
>   ret = -ENOMEM;
>   goto out;
>   }
> -- 
> 2.25.1