kernel.git/arch/s390/kernel/Makefile, branch linux-6.10.y

s390/kprobes: Remove custom insn slot allocator

2024-05-16T08:31:32Z

Since commit c98d2ecae08f ("s390/mm: Uncouple physical vs virtual address spaces") the kernel image and module area are within the same 4GB area. This eliminates the need of a custom insn slot allocator for kprobes within the kernel image, since standard module_alloc() allocated pages are sufficient for PC relative instructions with a signed 32 bit offset. Signed-off-by: Heiko Carstens

s390/ftrace: Use unwinder instead of __builtin_return_address()

2024-04-29T15:33:30Z

Using __builtin_return_address(n) might return undefined values when used with values of n outside of the stack. This was noticed when __builtin_return_address() was called in ftrace on top level functions like the interrupt handlers. As this behaviour cannot be fixed, use the s390 stack unwinder and remove the ftrace compilation flags for unwind_bc.c and stacktrace.c to prevent the unwinding function polluting function traces. Another advantage is that this also works with clang. Reviewed-by: Heiko Carstens Signed-off-by: Sven Schnelle Signed-off-by: Alexander Gordeev

arch, crash: move arch_crash_save_vmcoreinfo() out to file vmcore_info.c

2024-02-24T01:48:25Z

Nathan reported below building error: ===== $ curl -LSso .config https://git.alpinelinux.org/aports/plain/community/linux-edge/config-edge.armv7 $ make -skj"$(nproc)" ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- olddefconfig all .. arm-linux-gnueabi-ld: arch/arm/kernel/machine_kexec.o: in function `arch_crash_save_vmcoreinfo': machine_kexec.c:(.text+0x488): undefined reference to `vmcoreinfo_append_str' ==== On architecutres, like arm, s390, ppc, sh, function arch_crash_save_vmcoreinfo() is located in machine_kexec.c and it can only be compiled in when CONFIG_KEXEC_CORE=y. That's not right because arch_crash_save_vmcoreinfo() is used to export arch specific vmcoreinfo. CONFIG_VMCORE_INFO is supposed to control its compiling in. However, CONFIG_VMVCORE_INFO could be independent of CONFIG_KEXEC_CORE, e.g CONFIG_PROC_KCORE=y will select CONFIG_VMVCORE_INFO. Or CONFIG_KEXEC/CONFIG_KEXEC_FILE is set while CONFIG_CRASH_DUMP is not set, it will report linking error. So, on arm, s390, ppc and sh, move arch_crash_save_vmcoreinfo out to a new file vmcore_info.c. Let CONFIG_VMCORE_INFO decide if compiling in arch_crash_save_vmcoreinfo(). [akpm@linux-foundation.org: remove stray newlines at eof] Link: https://lkml.kernel.org/r/20240129135033.157195-3-bhe@redhat.com Signed-off-by: Baoquan He Reported-by: Nathan Chancellor Closes: https://lore.kernel.org/all/20240126045551.GA126645@dev-arch.thelio-3990X/T/#u Cc: Al Viro Cc: Eric W. Biederman Cc: Hari Bathini Cc: Klara Modin Cc: Michael Kelley Cc: Pingfan Liu Cc: Stephen Rothwell Cc: Yang Li Signed-off-by: Andrew Morton

KVM: s390: vsie: Fix length of facility list shadowed

2023-12-23T09:41:09Z

The length of the facility list accessed when interpretively executing STFLE is the same as the hosts facility list (in case of format-0) The memory following the facility list doesn't need to be accessible. The current VSIE implementation accesses a fixed length that exceeds the guest/host facility list length and can therefore wrongly inject a validity intercept. Instead, find out the host facility list length by running STFLE and copy only as much as necessary when shadowing. Acked-by: David Hildenbrand Reviewed-by: Claudio Imbrenda Acked-by: Heiko Carstens Signed-off-by: Nina Schoetterl-Glausch Reviewed-by: Janosch Frank Link: https://lore.kernel.org/r/20231219140854.1042599-3-nsg@linux.ibm.com Signed-off-by: Janosch Frank Message-ID: <20231219140854.1042599-3-nsg@linux.ibm.com>

s390/ctlreg: move control register code to separate file

2023-09-19T11:26:56Z

Control register handling has nothing to do with low level SMP code. Move it to a separate file. Reviewed-by: Alexander Gordeev Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik

s390/kexec: make machine_kexec() depend on CONFIG_KEXEC_CORE

2023-07-24T10:12:23Z

Make machine_kexec.o and relocate_kernel.o depend on CONFIG_KEXEC_CORE option as other architectures do. Still generate machine_kexec_reloc.o unconditionally, since arch_kexec_do_relocs() function is neded by the decompressor. Suggested-by: Nathan Chancellor Reported-by: Nathan Chancellor Reported-by: Linux Kernel Functional Testing Reviewed-by: Heiko Carstens Signed-off-by: Alexander Gordeev Signed-off-by: Heiko Carstens

s390: add support for user-defined certificates

2023-07-24T10:12:21Z

Enable receiving the user-defined certificates from the s390x hypervisor via new diagnose 0x320 calls, and make them available to the Linux root user as 'cert_store_key' type keys in a so-called 'cert_store' keyring. New user-space interfaces: /sys/firmware/cert_store/refresh Writing to this attribute re-fetches certificates via DIAG 0x320 /sys/firmware/cert_store/cs_status Reading from this attribute returns either of: "uninitialized" If no certificate has been retrieved yet "ok" If certificates have been successfully retrieved "failed ()" If certificate retrieval failed with reason code New debug trace areas: /sys/kernel/debug/s390dbf/cert_store_msg /sys/kernel/debug/s390dbf/cert_store_hexdump Usage example: To initiate request for certificates available to the system as root: $ echo 1 > /sys/firmware/cert_store/refresh Upon success the '/sys/firmware/cert_store/cs_status' contains the value 'ok'. $ cat /sys/firmware/cert_store/cs_status ok Get the ID of the keyring 'cert_store': $ keyctl search @us keyring cert_store OR $ keyctl link @us @s; keyctl request keyring cert_store Obtain list of IDs of certificates: $ keyctl rlist Display certificate content as hex-dump: $ keyctl read Read certificate contents as binary data: $ keyctl pipe >cert_data Display certificate description: $ keyctl describe The certificate description has the following format: <64 bytes certificate name in EBCDIC> ':' ':' The certificate description in /proc/keys has certificate name represented in ASCII. Users can read but cannot update the content of the certificate. Signed-off-by: Anastasia Eskova Reviewed-by: Peter Oberparleiter Acked-by: Heiko Carstens Signed-off-by: Heiko Carstens

rethook, fprobe: do not trace rethook related functions

2023-05-17T22:08:01Z

These functions are already marked as NOKPROBE to prevent recursion and we have the same reason to blacklist them if rethook is used with fprobe, since they are beyond the recursion-free region ftrace can guard. Link: https://lore.kernel.org/all/20230517034510.15639-5-zegao@tencent.com/ Fixes: f3a112c0c40d ("x86,rethook,kprobes: Replace kretprobe with rethook on x86") Signed-off-by: Ze Gao Reviewed-by: Steven Rostedt (Google) Acked-by: Masami Hiramatsu (Google) Cc: stable@vger.kernel.org Signed-off-by: Masami Hiramatsu (Google)

s390/cpum_cf: merge source files for CPU Measurement counter facility

2023-01-25T19:51:10Z

With no in-kernel user, the source files can be merged. Move all functions and the variable definitions to file perf_cpum_cf.c This file now contains all the necessary functions and definitions for the CPU Measurement counter facility device driver. The files cpu_mcf.h and perf_cpum_cf_common.c are deleted. Signed-off-by: Thomas Richter Acked-by: Hendrik Brueckner Signed-off-by: Heiko Carstens

s390/kprobes: replace kretprobe with rethook

2023-01-22T17:42:35Z

That's an adaptation of commit f3a112c0c40d ("x86,rethook,kprobes: Replace kretprobe with rethook on x86") to s390. Replaces the kretprobe code with rethook on s390. With this patch, kretprobe on s390 uses the rethook instead of kretprobe specific trampoline code. Tested-by: Ilya Leoshkevich Signed-off-by: Vasily Gorbik Signed-off-by: Heiko Carstens