- 13 Sep, 2019 2 commits
-
-
Joerg Schmidbauer authored
This patch introduces sha3 support for s390. - Rework the s390-specific SHA1 and SHA2 related code to provide the basis for SHA3. - Provide two new kernel modules sha3_256_s390 and sha3_512_s390 together with new kernel options. Signed-off-by:
Joerg Schmidbauer <jschmidb@de.ibm.com> Reviewed-by:
Ingo Franzki <ifranzki@linux.ibm.com> Reviewed-by:
Harald Freudenberger <freude@linux.ibm.com> Signed-off-by:
Heiko Carstens <heiko.carstens@de.ibm.com>
-
Vasily Gorbik authored
Try to print out startup pgm check info including exact linux kernel version, pgm interruption code and ilc, psw and general registers. Like the following: Linux version 5.3.0-rc7-07282-ge7b4d41d61bd-dirty (gor@tuxmaker) #3 SMP PREEMPT Thu Sep 5 16:07:34 CEST 2019 Kernel fault: interruption code 0005 ilc:2 PSW : 0000000180000000 0000000000012e52 R:0 T:0 IO:0 EX:0 Key:0 M:0 W:0 P:0 AS:0 CC:0 PM:0 RI:0 EA:3 GPRS: 0000000000000000 00ffffffffffffff 0000000000000000 0000000000019a58 000000000000bf68 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 000000000001a041 0000000000000000 0000000004c9c000 0000000000010070 0000000000012e42 000000000000beb0 This info makes it apparent that kernel startup failed and might help to understand what went wrong without actual standalone dump. Printing code runs on its own stack of 1 page (at unused 0x5000), which should be sufficient for sclp_early_printk usage (typical stack usage observed has been around 512 bytes). The code has pgm check recursion prevention, despite pgm check info printing failure (follow on pgm check) or success it restores original faulty psw and gprs and does disabled wait. Reviewed-by:Vasily Gorbik <gor@linux.ibm.com> Signed-off-by:
-
- 05 Sep, 2019 3 commits
-
-
Harald Freudenberger authored
With 'extra run-time crypto self tests' enabled, the selftest for s390-xts fails with alg: skcipher: xts-aes-s390 encryption unexpectedly succeeded on test vector "random: len=0 klen=64"; expected_error=-22, cfg="random: inplace use_digest nosimd src_divs=[2.61%@+4006, 84.44%@+21, 1.55%@+13, 4.50%@+344, 4.26%@+21, 2.64%@+27]" This special case with nbytes=0 is not handled correctly and this fix now makes sure that -EINVAL is returned when there is en/decrypt called with 0 bytes to en/decrypt. Signed-off-by:
-
Wei Yongjun authored
Fix to return negative error code -ENOMEM from the memory alloc failed error handling case instead of 0, as done elsewhere in this function. Fixes: 60e05d1c ("vfio-ccw: add some logging") Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Reviewed-by:
Cornelia Huck <cohuck@redhat.com> Link https://lore.kernel.org/kvm/20190904083315.105600-1-weiyongjun1@huawei.com/Signed-off-by:
Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by:
-
Halil Pasic authored
The intention seems to be to warn once when we don't wait enough for the reset to complete. Let's use the right retry counter to accomplish that semantic. Signed-off-by:
Halil Pasic <pasic@linux.ibm.com> Link: https://lore.kernel.org/r/20190903133618.9122-1-pasic@linux.ibm.comReviewed-by:
-
- 03 Sep, 2019 2 commits
-
-
Vasily Gorbik authored
s390_base_mcck_handler was used during system reset if diag308 set was not available. But after commit d485235b ("s390: assume diag308 set always works") is a dead code and could be removed. Acked-by:
-
Philipp Rudo authored
Fixes: c9896acc ("s390/ipl: Provide has_secure sysfs attribute") Cc: stable@vger.kernel.org # 5.2+ Reviewed-by:
Philipp Rudo <prudo@linux.ibm.com> Signed-off-by:
-
- 29 Aug, 2019 7 commits
-
-
Harald Freudenberger authored
Tests showed that the keygenflags parameter is not handled correctly within the zcrypt ccamisc generate cca cipher key code. A similar code is used with cca cipher key value import and there the flags are handled correctly. For unknown reason these lines have not been updated for the generate function and so this patch now introduces these two lines of code. This affects only pkey with the use of CCA cipher keys and the use of additional key generate flags. Fixes: 4bc123b1 ("s390/zcrypt: Add low level functions for CCA AES cipher keys") Signed-off-by:
-
Vasily Gorbik authored
Merge tag 'vfio-ccw-20190828' of https://git.kernel.org/pub/scm/linux/kernel/git/kvms390/vfio-ccw into features Add some logging into the s390dbf. * tag 'vfio-ccw-20190828' of https://git.kernel.org/pub/scm/linux/kernel/git/kvms390/vfio-ccw: vfio-ccw: add some logging Signed-off-by:
-
Vasily Gorbik authored
If kasan enabled kernel is used as crash kernel it crashes itself with program check loop during kdump execution. The reason for that is that kasan shadow memory backed by pages beyond OLDMEM_SIZE. Make kasan memory allocator respect physical memory limit imposed by kdump. Signed-off-by: -
Vasily Gorbik authored
Replace strncmp usage in console mode setup code with simple strcmp. Replace strncmp which is used for prefix comparison with str_has_prefix. Signed-off-by: -
Vasily Gorbik authored
"earlyprintk" option documentation does not clearly state which platform supports which additional values (e.g. ",keep"). Preserve old option behaviour and reuse str_has_prefix instead of strncmp for prefix testing. Signed-off-by: -
Vasily Gorbik authored
Reuse str_has_prefix instead of strncmp with hardcoded length to make the intent of a comparison more obvious. Signed-off-by: -
Vasily Gorbik authored
Command line option values passed to __setup callbacks are always null-terminated and "s390_iommu=" may only accept "strict" as value. So replace strncmp with strcmp. While at it also make s390_iommu_setup return 1, which means this command line option is handled by this callback. Signed-off-by:
-
- 26 Aug, 2019 7 commits
-
-
Vasily Gorbik authored
Sometimes the kernel fails to boot with: "The Linux kernel failed to boot with the KernelAddressSanitizer: out of memory during initialisation" even with big amounts of memory when both kaslr and kasan are enabled. The problem is that kasan initialization code requires 1/8 of physical memory plus some for page tables. To keep as much code instrumented as possible kasan avoids using memblock for memory allocations. Instead kasan uses trivial memory allocator which simply chops off the memory from the end of online physical memory. For that reason when kaslr is enabled together with kasan avoid positioning kernel into upper memory region which would be utilized during kasan initialization. Reviewed-by:
Gerald Schaefer <gerald.schaefer@de.ibm.com> Signed-off-by:
-
Vasily Gorbik authored
get_mem_detect_end is already used in couple of places with potential to be utilized in more cases. Provide single get_mem_detect_end implementation in asm/mem_detect.h to be used by kasan and startup code. Signed-off-by: -
Vasily Gorbik authored
"cmma" option setup already recognises some textual values. Yet kstrtobool is a more common way to parse boolean values, reuse it to unify option value parsing behavior and simplify code a bit. While at it, __setup value parsing callbacks are expected to return 1 when an option is recognized, and returning any other value won't trigger any error message currently, so simply return 1. Reviewed-by:
-
Vasily Gorbik authored
"vdso" option setup already recognises integer and textual values. Yet kstrtobool is a more common way to parse boolean values, reuse it to unify option value parsing behavior and simplify code a bit. While at it, __setup value parsing callbacks are expected to return 1 when an option is recognized, and returning any other value won't trigger any error message currently, so simply return 1. Also don't change default vdso_enabled value of 1 when "vdso" option value is invalid. Reviewed-by:
-
Vasily Gorbik authored
Check val is not NULL before accessing it. This might happen if corresponding kernel command line options are used without specifying values. Signed-off-by: -
Vasily Gorbik authored
Check "p" is not NULL before passing it to memparse, which doesn't handle that case explicitly. Signed-off-by: -
Vasily Gorbik authored
When command line options are used without specifying values (e.g. "emu_size" instead of "emu_size="), the value is NULL. Check that before performing string operations and further processing. Signed-off-by:
-
- 23 Aug, 2019 1 commit
-
-
Cornelia Huck authored
Usually, the common I/O layer logs various things into the s390 cio debug feature, which has been very helpful in the past when looking at crash dumps. As vfio-ccw devices unbind from the standard I/O subchannel driver, we lose some information there. Let's introduce some vfio-ccw debug features and log some things there. (Unfortunately we cannot reuse the cio debug feature from a module.) Message-Id: <20190816151505.9853-2-cohuck@redhat.com> Reviewed-by:
Eric Farman <farman@linux.ibm.com> Signed-off-by:
-
- 21 Aug, 2019 18 commits
-
-
Harald Freudenberger authored
The context used to store the key blob used a fixed 80 bytes buffer. And all the set_key functions did not even check the given key size. With CCA variable length AES cipher keys there come key blobs with about 136 bytes and maybe in the future there will arise the need to store even bigger key blobs. This patch reworks the paes set_key functions and the context buffers to work with small key blobs (<= 128 bytes) directly in the context buffer and larger blobs by allocating additional memory and storing the pointer in the context buffer. If there has been memory allocated for storing a key blob, it also needs to be freed on release of the tfm. So all the paes ciphers now have a init and exit function implemented for this job. Signed-off-by:
-
Harald Freudenberger authored
Introduce new ioctls and structs to be used with these new ioctls which are able to handle CCA AES secure keys and CCA AES cipher keys: PKEY_GENSECK2: Generate secure key, version 2. Generate either a CCA AES secure key or a CCA AES cipher key. PKEY_CLR2SECK2: Generate secure key from clear key value, version 2. Construct a CCA AES secure key or CCA AES cipher key from a given clear key value. PKEY_VERIFYKEY2: Verify the given secure key, version 2. Check for correct key type. If cardnr and domain are given, also check if this apqn is able to handle this type of key. If cardnr and domain are 0xFFFF, on return these values are filled with an apqn able to handle this key. The function also checks for the master key verification patterns of the key matching to the current or alternate mkvp of the apqn. CCA AES cipher keys are also checked for CPACF export allowed (CPRTCPAC flag). Currently CCA AES secure keys and CCA AES cipher keys are supported (may get extended in the future). PKEY_KBLOB2PROTK2: Transform a key blob (of any type) into a protected key, version 2. Difference to version 1 is only that this new ioctl has additional parameters to provide a list of apqns to be used for the transformation. PKEY_APQNS4K: Generate a list of APQNs based on the key blob given. Is able to find out which type of secure key is given (CCA AES secure key or CCA AES cipher key) and tries to find all matching crypto cards based on the MKVP and maybe other criterias (like CCA AES cipher keys need a CEX6C or higher). The list of APQNs is further filtered by the key's mkvp which needs to match to either the current mkvp or the alternate mkvp (which is the old mkvp on CCA adapters) of the apqns. The flags argument may be used to limit the matching apqns. If the PKEY_FLAGS_MATCH_CUR_MKVP is given, only the current mkvp of each apqn is compared. Likewise with the PKEY_FLAGS_MATCH_ALT_MKVP. If both are given it is assumed to return apqns where either the current or the alternate mkvp matches. If no matching APQN is found, the ioctl returns with 0 but the apqn_entries value is 0. PKEY_APQNS4KT: Generate a list of APQNs based on the key type given. Build a list of APQNs based on the given key type and maybe further restrict the list by given master key verification patterns. For different key types there may be different ways to match the master key verification patterns. For CCA keys (CCA data key and CCA cipher key) the first 8 bytes of cur_mkvp refer to the current mkvp value of the apqn and the first 8 bytes of the alt_mkvp refer to the old mkvp. The flags argument controls if the apqns current and/or alternate mkvp should match. If the PKEY_FLAGS_MATCH_CUR_MKVP is given, only the current mkvp of each apqn is compared. Likewise with the PKEY_FLAGS_MATCH_ALT_MKVP. If both are given, it is assumed to return apqns where either the current or the alternate mkvp matches. If no matching APQN is found, the ioctl returns with 0 but the apqn_entries value is 0. These new ioctls are now prepared for another new type of secure key blob which may come in the future. They all use a pointer to the key blob and a key blob length information instead of some hardcoded byte array. They all use the new enums pkey_key_type, pkey_key_size and pkey_key_info for getting/setting key type, key size and additional info about the key. All but the PKEY_VERIFY2 ioctl now work based on a list of apqns. This list is walked through trying to perform the operation on exactly this apqn without any further checking (like card type or online state). If the apqn fails, simple the next one in the list is tried until success (return 0) or the end of the list is reached (return -1 with errno ENODEV). All apqns in the list need to be exact apqns (0xFFFF as any card or domain is not allowed). There are two new ioctls which can be used to build a list of apqns based on a key or key type and maybe restricted by match to a current or alternate master key verifcation pattern. Signed-off-by:
-
Harald Freudenberger authored
This patch adds low level functions, structs and defines to support CCA AES cipher keys: - struct cipherkeytoken can be used for an inside view of the CCA AES cipher key token blob. - function cca_cipher2protkey() derives an CPACF protected key from an CCA AES cipher key. - function cca_gencipherkey() generates an CCA AES cipher key with random value. - function cca_findcard2() constructs a list of apqns based on input constrains like min hardware type, mkvp values. - cca_check_secaescipherkey() does a check on the given CCA AES cipher key blob. - cca_clr2cipherkey() generates an CCA AES cipher key from a given clear key value. Signed-off-by:
-
Harald Freudenberger authored
Rework and extension of the cca_findcard function to be prepared for other types of secure key blobs. Split the function and extract an internal function which has no awareness of key blobs any more. Improve this function and the helper code around to be able to check for a minimal crypto card hardware level (Background: the newer AES cipher keys need to match to the master key verification pattern and need to have a crypto card CEX6 or higher). No API change, neither for the in-kernel API nor the ioctl interface. Signed-off-by:
-
Harald Freudenberger authored
There are a lot of pkey functions exported as in-kernel callable API functions but not used at all. This patch narrows down the pkey in-kernel API to what is currently only used and exploited. Within the kernel just use u32 without any leading __u32. Also functions declared in a header file in arch/s390/include/asm don't need a comment 'In-kernel API', this is by definition, otherwise the header file would be in arch/s390/include/uapi/asm. Signed-off-by:
-
Vasily Gorbik authored
Make a usable value out of "mem" option once and for all. Kasan memory allocator just takes memory_end or online memory size as allocation base. If memory_end is not aligned paging structures allocated in kasan end up unaligned as well. So this change fixes potential kasan crash as well. Fixes: 78333d1f ("s390/kasan: add support for mem= kernel parameter") Signed-off-by:
-
Vasily Gorbik authored
Move .dma.text section alignment out of section description, otherwise zeros used to align the section are included in the section itself (and section is not really aligned by itself). $ objdump -h arch/s390/boot/compressed/vmlinux 5 .dma.text 00001e38 000000000001b1c8 000000000001b1c8 0001c1c8 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 6 .dma.ex_table 00000018 000000000001d000 000000000001d000 0001e000 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 7 .dma.data 00000240 000000000001d080 000000000001d080 0001e080 2**7 CONTENTS, ALLOC, LOAD, DATA $ cat /sys/kernel/debug/memblock/reserved 0: 0x0000000000000000..0x0000000000011fff 1: 0x000000000001b1c8..0x000000000001d2bf ... Also add alignment before _edma linker symbol definition, so that entire .dma* region is rounded up to page boundaries. $ objdump -h arch/s390/boot/compressed/vmlinux 5 .dma.text 00001000 000000000001c000 000000000001c000 0001d000 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 6 .dma.ex_table 00000018 000000000001d000 000000000001d000 0001e000 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 7 .dma.data 00000240 000000000001d080 000000000001d080 0001e080 2**7 CONTENTS, ALLOC, LOAD, DATA $ cat /sys/kernel/debug/memblock/reserved 0: 0x0000000000000000..0x0000000000011fff 1: 0x000000000001c000..0x000000000001dfff ... $ cat /sys/kernel/debug/kernel_page_tables ---[ Identity Mapping ]--- 0x0000000000000000-0x000000000001c000 112K PTE RW NX 0x000000000001c000-0x000000000001d000 4K PTE RO X 0x000000000001d000-0x0000000000100000 908K PTE RW NX ... Reviewed-by: -
Vasily Gorbik authored
Use common arch_stack_walk infrastructure to avoid duplicated code and avoid taking care of the stack storage and filtering. Common code also uses try_get_task_stack/put_task_stack when needed which have been missing in our code, which also solves potential problem for us. Signed-off-by: -
Vasily Gorbik authored
Reading other running task's stack can be a dangerous endeavor. Kasan stack memory access instrumentation includes special prologue and epilogue to mark/remove red zones in shadow memory between stack variables. For that reason there is always a race between a task reading value in other task's stack and that other task returning from a function and entering another one generating different red zones pattern. To avoid kasan reports simply perform uninstrumented memory reads. Acked-by:
Ilya Leoshkevich <iii@linux.ibm.com> Signed-off-by:
-
Vasily Gorbik authored
With THREAD_INFO_IN_TASK (which is selected on s390) task's stack usage is refcounted and should always be protected by get/put when touching other task's stack to avoid race conditions with task's destruction code. Fixes: d5c352cd ("s390: move thread_info into task_struct") Cc: stable@vger.kernel.org # v4.10+ Acked-by:
-
Vasily Gorbik authored
s390 kasan code uses sclp_early_printk to report initialization failures. The code doing that should not be instrumented, because kasan shadow memory has not been set up yet. Even though sclp_early_core.c is compiled with instrumentation disabled it uses strlen function, which is instrumented and would produce shadow memory access if used. To avoid that, introduce uninstrumented __strlen function to be used instead. Before commit 7e0d92f0 ("s390/kasan: improve string/memory functions checks") few string functions (including strlen) were escaping kasan instrumentation due to usage of platform specific versions which are implemented in inline assembly. Fixes: 7e0d92f0 ("s390/kasan: improve string/memory functions checks") Acked-by:
-
Vasily Gorbik authored
Clean uncompressed kernel .bss section in the startup code before the uncompressed kernel is executed. At this point of time initrd and certificates have been already rescued. Uncompressed kernel .bss size is known from vmlinux_info. It is also taken into consideration during uncompressed kernel positioning by kaslr (so it is safe to clean it). With that uncompressed kernel is starting with .bss section zeroed and no .bss section usage restrictions apply. Which makes chkbss checks for uncompressed kernel objects obsolete and they can be removed. early_nobss.c is also not needed anymore. Parts of it which are still relevant are moved to early.c. Kasan initialization code is now called directly from head64 (early.c is instrumented and should not be executed before kasan shadow memory is set up). Reviewed-by:
-
Vasily Gorbik authored
sizes.h and vmlinux.scr.lds are not generated since commit 369f91c3 ("s390/decompressor: rework uncompressed image info collection"). vmlinux.bin.full is not generated since commit 183ab05f ("s390: get rid of the first mb of uncompressed image"). Signed-off-by:
-
Vasily Gorbik authored
The startup code is getting more complicated with features like kaslr and secure boot in place. In a potential unexpected startup code crash case the system would end up in a pgm check loop at address 0, overwriting pgm check old psw value and just making debugging more complicated. To avoid that introduce startup program check handler which is active immediately after kernel start and until early_pgm_check_handler is set in kernel/early.c. So it covers kernel relocation phase and transition to it. This pgm check handler simply saves general/control registers and psw in the save area which should guarantee that we still have something to look at when standalone dumper is called without saving registers. And it does disabled wait with a faulty address in the end. Acked-by:
-
Chuhong Yuan authored
Reference counters are preferred to use refcount_t instead of atomic_t. This is because the implementation of refcount_t can prevent overflows and detect possible use-after-free. So convert atomic_t ref counters to refcount_t. Link: http://lkml.kernel.org/r/20190808071826.6649-1-hslester96@gmail.comSigned-off-by:
Chuhong Yuan <hslester96@gmail.com> Reviewed-by:
David Hildenbrand <david@redhat.com> Reviewed-by:
-
Chuhong Yuan authored
Reference counters are preferred to use refcount_t instead of atomic_t. This is because the implementation of refcount_t can prevent overflows and detect possible use-after-free. So convert atomic_t ref counters to refcount_t. Link: http://lkml.kernel.org/r/20190808071817.6595-1-hslester96@gmail.comSigned-off-by:
-
Denis Efremov authored
This patch alters the for loop iteration scheme in zpci_map_resources to make it more usual. Thus, the patch generalizes the style for PCI_IOV_RESOURCES iteration and improves readability. Link: http://lkml.kernel.org/r/20190806160137.29275-1-efremov@linux.comSigned-off-by:
Denis Efremov <efremov@linux.com> Signed-off-by:
Sebastian Ott <sebott@linux.ibm.com> Signed-off-by:
-
Vasily Gorbik authored
Few other crucial memory setup options are already handled in the startup code. Those values are needed by kaslr and kasan implementations. "vmalloc" is the last piece required for future improvements such as early decision on kernel page levels depth required for actual memory setup, as well as vmalloc memory area access monitoring in kasan. Reviewed-by:
-
