Pull integrity updates from Mimi Zohar:
 "There are two main changes, one feature removal, some code cleanup,
  and a number of bug fixes.

  Main changes:
   - Detecting secure boot mode was limited to IMA. Make detecting
     secure boot mode accessible to EVM and other LSMs
   - IMA sigv3 support was limited to fsverity. Add IMA sigv3 support
     for IMA regular file hashes and EVM portable signatures

  Remove:
   - Remove IMA support for asychronous hash calculation originally
     added for hardware acceleration

  Cleanup:
   - Remove unnecessary Kconfig CONFIG_MODULE_SIG and CONFIG_KEXEC_SIG
     tests
   - Add descriptions of the IMA atomic flags

  Bug fixes:
   - Like IMA, properly limit EVM "fix" mode
   - Define and call evm_fix_hmac() to update security.evm
   - Fallback to using i_version to detect file change for filesystems
     that do not support STATX_CHANGE_COOKIE
   - Address missing kernel support for configured (new) TPM hash
     algorithms
   - Add missing crypto_shash_final() return value"

* tag 'integrity-v7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity:
  evm: Enforce signatures version 3 with new EVM policy 'bit 3'
  integrity: Allow sigv3 verification on EVM_XATTR_PORTABLE_DIGSIG
  ima: add support to require IMA sigv3 signatures
  ima: add regular file data hash signature version 3 support
  ima: Define asymmetric_verify_v3() to verify IMA sigv3 signatures
  ima: remove buggy support for asynchronous hashes
  integrity: Eliminate weak definition of arch_get_secureboot()
  ima: Add code comments to explain IMA iint cache atomic_flags
  ima_fs: Correctly create securityfs files for unsupported hash algos
  ima: check return value of crypto_shash_final() in boot aggregate
  ima: Define and use a digest_size field in the ima_algo_desc structure
  powerpc/ima: Drop unnecessary check for CONFIG_MODULE_SIG
  ima: efi: Drop unnecessary check for CONFIG_MODULE_SIG/CONFIG_KEXEC_SIG
  ima: fallback to using i_version to detect file change
  evm: fix security.evm for a file with IMA signature
  s390: Drop unnecessary CONFIG_IMA_SECURE_AND_OR_TRUSTED_BOOT
  evm: Don't enable fix mode when secure boot is enabled
  integrity: Make arch_ima_get_secureboot integrity-wide

Commit b5ca117365d9 ("ima: prevent kexec_load syscall based on runtime
secureboot flag") and commit 268a78404973 ("s390/kexec_file: Disable
kexec_load when IPLed secure") disabled the kexec_load syscall based
on the secureboot mode. Commit 9e2b4be377f0 ("ima: add a new CONFIG
for loading arch-specific policies") needed to detect the secure boot
mode, not to load an IMA architecture specific policy. Since there is
the new CONFIG_INTEGRITY_SECURE_BOOT, drop
CONFIG_IMA_SECURE_AND_OR_TRUSTED_BOOT for s390.

Signed-off-by: Coiby Xu <coxu@redhat.com>
Tested-by: Alexander Egorenkov <egorenar@linux.ibm.com>
[Vasily Gorbik: Fix missing arch_get_secureboot() prototype warning]
link: https://lore.kernel.org/linux-integrity/c00-01.ttbfdx5@ub.hpns/
Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>

Implementing BPF version of preempt_count() requires accessing lowcore
from BPF. Since lowcore can be relocated, open-coding
(struct lowcore *)0 does not work, so add a kfunc.

Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Link: https://lore.kernel.org/r/20260217160813.100855-2-iii@linux.ibm.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>

Since compat is gone there is only a 64 bit vdso left.
Remove the superfluous "64" suffix everywhere.

Reviewed-by: Jens Remus <jremus@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>

All the code is 64 bit, therefore remove the superfluous suffix.

Reviewed-by: Jens Remus <jremus@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>

Stackprotector support was previously unavailable on s390 because by
default compilers generate code which is not suitable for the kernel:
the canary value is accessed via thread local storage, where the address
of thread local storage is within access registers 0 and 1.

Using those registers also for the kernel would come with a significant
performance impact and more complicated kernel entry/exit code, since
access registers contents would have to be exchanged on every kernel entry
and exit.

With the upcoming gcc 16 release new compiler options will become available
which allow to generate code suitable for the kernel. [1]

Compiler option -mstack-protector-guard=global instructs gcc to generate
stackprotector code that refers to a global stackprotector canary value via
symbol __stack_chk_guard. Access to this value is guaranteed to occur via
larl and lgrl instructions.

Furthermore, compiler option -mstack-protector-guard-record generates a
section containing all code addresses that reference the canary value.

To allow for per task canary values the instructions which load the address
of __stack_chk_guard are patched so they access a lowcore field instead: a
per task canary value is available within the task_struct of each task, and
is written to the per-cpu lowcore location on each context switch.

Also add sanity checks and debugging option to be consistent with other
kernel code patching mechanisms.

Full debugging output can be enabled with the following kernel command line
options:

debug_stackprotector
bootdebug
ignore_loglevel
earlyprintk
dyndbg="file stackprotector.c +p"

Example debug output:

stackprot: 0000021e402d4eda: c010005a9ae3 -> c01f00070240

where "<insn address>: <old insn> -> <new insn>".

[1] gcc commit 0cd1f03939d5 ("s390: Support global stack protector")

Reviewed-by: Sven Schnelle <svens@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>

There shouldn't be any 31 bit code around anymore that matters.
Remove the compat layer support required to run 31 bit code.

Reason for removal is code simplification and reduced test effort.

Note that this comes without any deprecation warnings added to config
options, or kernel messages, since most likely those would be ignored
anyway.

If it turns out there is still a reason to keep the compat layer this
can be reverted at any time in the future.

Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>

Rename perf_pai_crypto.c to perf_pai.c. The new perf_pai.c
contains both PAI device drivers:
 - pai_crypto for PAI crypto counter set
 - pai_ext for PAI NNPA counter set
The rename reflects this common driver supporting both PMUs.

Signed-off-by: Thomas Richter <tmricht@linux.ibm.com>
Reviewed-by: Jan Polensky <japo@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>

Combine PAI cryptography and PAI extension (NNPA) PMUs in one driver.
Remove file perf_pai_ext.c and registration of PMU "pai_ext"
from perf_pai_crypto.c.

Includes:
- Shared alloc/free and sched_task handling
- NNPA events with exclude_kernel enforced, exclude_user rejected
- Setup CR0 bits for both PMUs

Signed-off-by: Thomas Richter <tmricht@linux.ibm.com>
Reviewed-by: Jan Polensky <japo@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>

The current assumption is that kernel code is always executed with access
key zero, which means that storage key protection does not apply.

However this assumption is not correct: cmpxchg_user_key() may be executed
with a non-zero key; if then the storage key of the page which belongs to
the cmpxchg_user_key() code contains a key with fetch-protection enabled
the result is a protection exception.

For several performance optimizations storage keys are not initialized on
system boot. To keep these optimizations add infrastructure which allows to
define code ranges within functions which are executed with a non-default
key. When such code is executed such functions must explicitly call
skey_regions_initialize().

This will initialize all storage keys belonging to such code ranges in a
way that no protection exceptions happen when the code is executed with a
non-default access key.

Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>