- 19 Apr, 2023 2 commits
-
-
Thomas Richter authored
The CPU measurement facility counter information instruction qctri() retrieves information about the available counter sets. The information varies between machine generations, but is constant when running on a particular machine. For example the CPU measurement facility counter first and second version numbers determine the amount of counters in a counter set. This information never changes. The counter sets are identical for all CPUs in the system. It does not matter which CPU performs the instruction. Authorization control of the CPU Measurement facility can only be changed in the activation profile while the LPAR is not running. Retrieve the CPU measurement counter information at device driver initialization time and use its constant values. Function validate_ctr_version() verifies if a user provided CPU Measurement counter facility counter is valid and defined. It now uses the newly introduced static CPU counter facility information. To avoid repeated recalculation of the counter set sizes (numbers of counters per set), which never changes on a running machine, calculate the counter set size once at device driver initialization and store the result in an array. Functions cpum_cf_make_setsize() and cpum_cf_read_setsize() are introduced. Finally remove cpu_cf_events::info member and use the static CPU counter facility information instead. Signed-off-by:
Thomas Richter <tmricht@linux.ibm.com> Acked-by:
Heiko Carstens <hca@linux.ibm.com> Acked-by:
Sumanth Korikkar <sumanthk@linux.ibm.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com>
-
Harald Freudenberger authored
Review and rework all the zero length array occurrences within structs to flexible array fields or comment if not used at all. However, some struct fields are there for documentation purpose or to have correct sizeof() evaluation of a struct and thus should not get deleted. Signed-off-by:
Harald Freudenberger <freude@linux.ibm.com> Acked-by:
Holger Dengler <dengler@linux.ibm.com> Signed-off-by:
-
- 13 Apr, 2023 25 commits
-
-
Heiko Carstens authored
There are numerous patches which convert zero-length arrays with a flexible-array member. Convert the remaining s390 occurrences. Suggested-by:
Gustavo A. R. Silva <gustavoars@kernel.org> Link: https://github.com/KSPP/linux/issues/78 Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602902.htmlSigned-off-by:
-
Heiko Carstens authored
There are numerous patches which convert zero-length arrays with a flexible-array member. Convert the remaining s390 occurrences. Suggested-by:
-
Heiko Carstens authored
There are numerous patches which convert zero-length arrays with a flexible-array member. Convert the remaining s390 occurrences. Suggested-by:
-
Gustavo A. R. Silva authored
Zero-length arrays are deprecated [1] and have to be replaced by C99 flexible-array members. This helps with the ongoing efforts to tighten the FORTIFY_SOURCE routines on memcpy() and help to make progress towards globally enabling -fstrict-flex-arrays=3 [2] Link: https://github.com/KSPP/linux/issues/78 [1] Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602902.html [2] Signed-off-by:
-
Gustavo A. R. Silva authored
Zero-length arrays are deprecated [1] and have to be replaced by C99 flexible-array members. This helps with the ongoing efforts to tighten the FORTIFY_SOURCE routines on memcpy() and help to make progress towards globally enabling -fstrict-flex-arrays=3 [2] Link: https://github.com/KSPP/linux/issues/78 [1] Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602902.html [2] Signed-off-by:
-
Heiko Carstens authored
Commit bb1520d5 ("s390/mm: start kernel with DAT enabled") did not implement direct map accounting in the early page table setup code. In result the reported values are bogus now: $cat /proc/meminfo ... DirectMap4k: 5120 kB DirectMap1M: 18446744073709546496 kB DirectMap2G: 0 kB Fix this by adding the missing accounting. The result looks sane again: $cat /proc/meminfo ... DirectMap4k: 6156 kB DirectMap1M: 2091008 kB DirectMap2G: 6291456 kB Fixes: bb1520d5 ("s390/mm: start kernel with DAT enabled") Reviewed-by:
Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by:
-
Heiko Carstens authored
Architectures generally use the "direct map" wording for mapping the whole physical memory. Use that wording as well in arch/s390/boot/vmem.c, instead of "one to one" in order to avoid confusion. This also matches what is already done in arch/s390/mm/vmem.c. Reviewed-by:
-
Marc Hartmayer authored
Use proper quoting for the variables and explicitly distinguish between command options and positional arguments. Acked-by:
Marc Hartmayer <mhartmay@linux.ibm.com> Signed-off-by:
-
Thomas Richter authored
Simplify pr_err() statement into one line and omit return statement. No functional change. Signed-off-by:
-
Vasily Gorbik authored
When the KASLR is enabled, randomize the base address of the amode31 image within the first 2 GB, similar to the approach taken for the vmlinux image. This makes it harder to predict the location of amode31 data and code. Reviewed-by:
-
Vasily Gorbik authored
Improve the distribution algorithm of random base address to ensure a uniformity among all suitable addresses. To generate a random value once, and to build a continuous range in which every value is suitable, count all the suitable addresses (referred to as positions) that can be used as a base address. The positions are counted by iterating over the usable memory ranges. For each range that is big enough to accommodate the image, count all the suitable addresses where the image can be placed, while taking reserved memory ranges into consideration. A new function "iterate_valid_positions()" has dual purpose. Firstly, it is called to count the positions in a given memory range, and secondly, to convert a random position back to an address. "get_random_base()" has been replaced with more generic "randomize_within_range()" which now could be called for randomizing base addresses not just for the kernel image. Acked-by:
-
Vasily Gorbik authored
The special amode31 part of the kernel must always remain below 2Gb. Place it just under vmlinux.default_lma by default, which makes it easier to debug amode31 as its default lma is known 0x10000 - 0x3000 (currently, amode31's size is 3 pages). This location is always available as it is originally occupied by the vmlinux archive. Reviewed-by:
-
Vasily Gorbik authored
The current modification of the default_lma is illogical and should be avoided. It would be more appropriate to introduce and utilize a new variable vmlinux_lma instead, so that default_lma remains unchanged and at its original "default" value of 0x100000. Signed-off-by: -
Thomas Richter authored
Struct s390_ctrset_read userdata is filled by ioctl_read operation using put_user/copy_to_user. However, the ctrset->data value access is not performed anywhere during the ioctl_read operation. Remove unnecessary copy_from_user() call. No functional change. Signed-off-by:
-
Thomas Richter authored
When function cfset_all_copy() fails, also log the bad return code in the debug statement (when turned on). No functional change Signed-off-by:
-
Heiko Carstens authored
This is the s390 variant of commit 7dfac3c5 ("arm64: module: create module allocations without exec permissions"): "The core code manages the executable permissions of code regions of modules explicitly. It is no longer necessary to create the module vmalloc regions with RWX permissions. So create them with RW- permissions instead, which is preferred from a security perspective." Reviewed-by:
-
Heiko Carstens authored
The ftrace code assumes at two places that module_alloc() returns executable memory. While this is currently true, this will be changed with a subsequent patch to follow other architectures which implement ARCH_HAS_STRICT_MODULE_RWX. Acked-by:
-
Heiko Carstens authored
Given that set_memory_rox() and set_memory_rwnx() exist, it is possible to get rid of all open coded __set_memory() usages and replace them with proper helper calls everywhere. Reviewed-by:
-
Heiko Carstens authored
Given that set_memory_rox() is implemented, provide also set_memory_rwnx(). This allows to get rid of all open coded __set_memory() usages in s390 architecture code. Reviewed-by:
-
Heiko Carstens authored
Provide the s390 specific native set_memory_rox() implementation to avoid frequent set_memory_ro(); set_memory_x() call pairs. This is the s390 variant of commit 60463628 ("x86/mm: Implement native set_memory_rox()"). Reviewed-by:
-
Nico Boehr authored
Diag 308 subcodes expect a physical address as their parameter. This currently is not a bug, but in the future physical and virtual addresses might differ. Fix the confusion by doing a virtual-to-physical conversion in the exported diag308() and leave the assembly wrapper __diag308() alone. Note that several callers pass NULL as addr, so check for the case when NULL is passed and pass 0 to hardware since virt_to_phys(0) might be nonzero. Suggested-by:
Nico Boehr <nrb@linux.ibm.com> Signed-off-by:
-
Heiko Carstens authored
Randomize the load address of modules in the kernel to make KASLR effective for modules. This is the s390 variant of commit e2b32e67 ("x86, kaslr: randomize module base load address"). Reviewed-by:
-
Heiko Carstens authored
Just like other architectures provide a kaslr_enabled() function, instead of directly accessing a global variable. Also pass the renamed __kaslr_enabled variable from the decompressor to the kernel, so that kalsr_enabled() is available there too. This will be used by a subsequent patch which randomizes the module base load address. Reviewed-by:
-
Heiko Carstens authored
Signed-off-by:
-
Heiko Carstens authored
Commit dfe843dc ("s390/checksum: support GENERIC_CSUM, enable it for KASAN") switched s390 to use the generic checksum functions, so that KASAN instrumentation also works checksum functions by avoiding architecture specific inline assemblies. There is however the problem that the generic csum_partial() function returns a 32 bit value with a 16 bit folded checksum, while the original s390 variant does not fold to 16 bit. This in turn causes that the ipib_checksum in lowcore contains different values depending on kernel config options. The ipib_checksum is used by system dumpers to verify if pointers in lowcore point to valid data. Verification is done by comparing checksum values. The system dumpers still use 32 bit checksum values which are not folded, and therefore the checksum verification fails (incorrectly). Symptom is that reboot after dump does not work anymore when a KASAN instrumented kernel is dumped. Fix this by not using the generic checksum implementation. Instead add an explicit kasan_check_read() so that KASAN knows about the read access from within the inline assembly. Reported-by:
Alexander Egorenkov <egorenar@linux.ibm.com> Fixes: dfe843dc ("s390/checksum: support GENERIC_CSUM, enable it for KASAN") Tested-by:
-
- 04 Apr, 2023 13 commits
-
-
Heiko Carstens authored
Add support for the stackleak feature. Whenever the kernel returns to user space the kernel stack is filled with a poison value. Enabling this feature is quite expensive: e.g. after instrumenting the getpid() system call function to have a 4kb stack the result is an increased runtime of the system call by a factor of 3. Reviewed-by:
-
Heiko Carstens authored
As preparation for the stackleak feature move on_thread_stack() to processor.h like x86. Also make it __always_inline, and slightly optimize it by reading current task's kernel stack pointer from lowcore. Reviewed-by:
-
Heiko Carstens authored
Allocate early async stack like other early stacks and get rid of arch_early_irq_init(). This way the async stack is allocated earlier, and handled like all other stacks. Reviewed-by:
-
Heiko Carstens authored
There is no user left of call_on_stack_noreturn() - remove it. Reviewed-by:
-
Heiko Carstens authored
s390 is the only architecture which switches from the initial stack to a later on allocated different stack for the first process. This is (at least) problematic for the stackleak feature, which instruments functions to save the current stackpointer within the task structure of the running process. The stackleak code compares stack pointers of the current process - and doesn't expect that the kernel stack of a task can change. Even though the stackleak feature itself will not cause any harm, the assumption about kernel stacks being consistent is there, and only s390 doesn't follow that. Therefore switch back to use init_thread_union, just like all other architectures. Reviewed-by:
-
Heiko Carstens authored
Make sure the lowcore kernel stack pointer reflects the kernel stack of the current task as early as possible, instead of having a NULL pointer there. Reviewed-by:
-
Heiko Carstens authored
Make STACK_INIT_OFFSET also available for assembler code, and use it everywhere instead of open-coding it at several places. Reviewed-by:
-
Heiko Carstens authored
The pattern for all in_<type>_stack() functions is the same; especially also the size of all stacks is the same. Simplify the code by passing only the stack address to the generic in_stack() helper, which then can assume a THREAD_SIZE sized stack. Reviewed-by:
-
Harald Freudenberger authored
The preparation of the key data struct for a CCA RSA ME operation had some improvement to skip leading zeros in the key's exponent. However, all supported CCA cards nowadays support leading zeros in key tokens. So for simplifying the CCA key preparing code, this patch simply removes this optimization code. Signed-off-by:
Juergen Christ <jchrist@linux.ibm.com> Reviewed-by:
-
Harald Freudenberger authored
There was some ancient code which padded the results of a clear key ME or CRT operation with some PKCS 1.2 header. According to the comment this was only needed by crypto cards older than the CEX2. These cards are not supported any more and so this patch removes this obscure result padding code. Signed-off-by:
-
Vasily Gorbik authored
Currently, exception tables are marked as ro_after_init. However, since they are sorted during compile time using scripts/sorttable, they can be moved to RO_DATA using the RO_EXCEPTION_TABLE_ALIGN macro, which is specifically designed for this purpose. Suggested-by:
-
Vasily Gorbik authored
Since commit 4efd417f ("s390: raise minimum supported machine generation to z10"), the long-displacement facility is assumed and required for the kernel. Clean up a couple of places in the entry code, where long-displacement could be used directly instead of using a base register. However, there are still a few other places where a base register has to be used to extend short-displacement for the second lowcore page access. Notably, boot/head.S still has to be built for z900, and in mcck_int_handler, spt and lbear, which don't have long-displacements, but need to access save areas at the second lowcore page. Reviewed-by:
-
Vasily Gorbik authored
Heiko Carstens says: =================== There are a couple of oddities within the s390 uaccess library functions. Therefore cleanup the whole uaccess.c file. There is no functional change, only improved readability. The output of "objdump -Dr" was always compared before/after each patch to make sure that the generated object file is identical, if that could be expected. Therefore the series also includes more patches than really required to cleanup the code. Furthermore the kunit usercopy tests also still pass. =================== Signed-off-by:
-
