Commit Graph
100 Commits
Author SHA1 Message Date
Vasily Gorbik d5372c3913 kexec: restore arch_kexec_kernel_image_probe declaration
arch_kexec_kernel_image_probe function declaration has been removed by
commit 9ec4ecef0a ("kexec_file,x86,powerpc: factor out kexec_file_ops
functions").  Still this function is overridden by couple of architectures
and proper prototype declaration is therefore important, so bring it back.
This fixes the following sparse warning on s390:
arch/s390/kernel/machine_kexec_file.c:333:5: warning: symbol
'arch_kexec_kernel_image_probe' was not declared.  Should it be static?

Link: http://lkml.kernel.org/r/patch.git-ff1c9045ebdc.your-ad-here.call-01564402297-ext-5690@work.hours
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Acked-by: Dave Young <dyoung@redhat.com>
Reviewed-by: Bhupesh Sharma <bhsharma@redhat.com>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-09-25 17:51:40 -07:00
Vasily Gorbik ab57588480 s390/cio: exclude subchannels with no parent from pseudo check
ccw console is created early in start_kernel and used before css is
initialized or ccw console subchannel is registered. Until then console
subchannel does not have a parent. For that reason assume subchannels
with no parent are not pseudo subchannels. This fixes the following
kasan finding:

BUG: KASAN: global-out-of-bounds in sch_is_pseudo_sch+0x8e/0x98
Read of size 8 at addr 00000000000005e8 by task swapper/0/0

CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.3.0-rc8-07370-g6ac43dd12538 #2
Hardware name: IBM 2964 NC9 702 (z/VM 6.4.0)
Call Trace:
([<000000000012cd76>] show_stack+0x14e/0x1e0)
 [<0000000001f7fb44>] dump_stack+0x1a4/0x1f8
 [<00000000007d7afc>] print_address_description+0x64/0x3c8
 [<00000000007d75f6>] __kasan_report+0x14e/0x180
 [<00000000018a2986>] sch_is_pseudo_sch+0x8e/0x98
 [<000000000189b950>] cio_enable_subchannel+0x1d0/0x510
 [<00000000018cac7c>] ccw_device_recognition+0x12c/0x188
 [<0000000002ceb1a8>] ccw_device_enable_console+0x138/0x340
 [<0000000002cf1cbe>] con3215_init+0x25e/0x300
 [<0000000002c8770a>] console_init+0x68a/0x9b8
 [<0000000002c6a3d6>] start_kernel+0x4fe/0x728
 [<0000000000100070>] startup_continue+0x70/0xd0

Cc: stable@vger.kernel.org
Reviewed-by: Sebastian Ott <sebott@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-09-23 23:27:53 +02:00
Vasily Gorbik ea298e6ee8 s390/cio: avoid calling strlen on null pointer
Fix the following kasan finding:
BUG: KASAN: global-out-of-bounds in ccwgroup_create_dev+0x850/0x1140
Read of size 1 at addr 0000000000000000 by task systemd-udevd.r/561

CPU: 30 PID: 561 Comm: systemd-udevd.r Tainted: G    B
Hardware name: IBM 3906 M04 704 (LPAR)
Call Trace:
([<0000000231b3db7e>] show_stack+0x14e/0x1a8)
 [<0000000233826410>] dump_stack+0x1d0/0x218
 [<000000023216fac4>] print_address_description+0x64/0x380
 [<000000023216f5a8>] __kasan_report+0x138/0x168
 [<00000002331b8378>] ccwgroup_create_dev+0x850/0x1140
 [<00000002332b618a>] group_store+0x3a/0x50
 [<00000002323ac706>] kernfs_fop_write+0x246/0x3b8
 [<00000002321d409a>] vfs_write+0x132/0x450
 [<00000002321d47da>] ksys_write+0x122/0x208
 [<0000000233877102>] system_call+0x2a6/0x2c8

Triggered by:
openat(AT_FDCWD, "/sys/bus/ccwgroup/drivers/qeth/group",
		O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 16
write(16, "0.0.bd00,0.0.bd01,0.0.bd02", 26) = 26

The problem is that __get_next_id in ccwgroup_create_dev might set "buf"
buffer pointer to NULL and explicit check for that is required.

Cc: stable@vger.kernel.org
Reviewed-by: Sebastian Ott <sebott@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-09-23 23:27:52 +02:00
Vasily Gorbik f3122a79a1 s390/topology: avoid firing events before kobjs are created
arch_update_cpu_topology is first called from:
kernel_init_freeable->sched_init_smp->sched_init_domains

even before cpus has been registered in:
kernel_init_freeable->do_one_initcall->s390_smp_init

Do not trigger kobject_uevent change events until cpu devices are
actually created. Fixes the following kasan findings:

BUG: KASAN: global-out-of-bounds in kobject_uevent_env+0xb40/0xee0
Read of size 8 at addr 0000000000000020 by task swapper/0/1

BUG: KASAN: global-out-of-bounds in kobject_uevent_env+0xb36/0xee0
Read of size 8 at addr 0000000000000018 by task swapper/0/1

CPU: 0 PID: 1 Comm: swapper/0 Tainted: G    B
Hardware name: IBM 3906 M04 704 (LPAR)
Call Trace:
([<0000000143c6db7e>] show_stack+0x14e/0x1a8)
 [<0000000145956498>] dump_stack+0x1d0/0x218
 [<000000014429fb4c>] print_address_description+0x64/0x380
 [<000000014429f630>] __kasan_report+0x138/0x168
 [<0000000145960b96>] kobject_uevent_env+0xb36/0xee0
 [<0000000143c7c47c>] arch_update_cpu_topology+0x104/0x108
 [<0000000143df9e22>] sched_init_domains+0x62/0xe8
 [<000000014644c94a>] sched_init_smp+0x3a/0xc0
 [<0000000146433a20>] kernel_init_freeable+0x558/0x958
 [<000000014599002a>] kernel_init+0x22/0x160
 [<00000001459a71d4>] ret_from_fork+0x28/0x30
 [<00000001459a71dc>] kernel_thread_starter+0x0/0x10

Cc: stable@vger.kernel.org
Reviewed-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-09-23 23:27:52 +02:00
Vasily Gorbik 724dc336b7 s390/startup: add pgm check info printing
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: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-09-13 12:17:37 +02:00
Vasily Gorbik 512222789c s390/base: remove unused s390_base_mcck_handler
s390_base_mcck_handler was used during system reset if diag308 set was
not available. But after commit d485235b00 ("s390: assume diag308 set
always works") is a dead code and could be removed.

Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-09-03 13:53:56 +02:00
Vasily Gorbik 58879d468a 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 <gor@linux.ibm.com>
2019-08-29 15:38:40 +02:00
Vasily Gorbik 042c1d29de s390/kasan: add kdump support
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 <gor@linux.ibm.com>
2019-08-29 15:34:58 +02:00
Vasily Gorbik d0b319843b s390/setup: avoid using strncmp with hardcoded length
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 <gor@linux.ibm.com>
2019-08-29 15:34:58 +02:00
Vasily Gorbik 54fb07d030 s390/sclp: avoid using strncmp with hardcoded length
"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 <gor@linux.ibm.com>
2019-08-29 15:34:58 +02:00
Vasily Gorbik b29cd7c4c4 s390/module: avoid using strncmp with hardcoded length
Reuse str_has_prefix instead of strncmp with hardcoded length to
make the intent of a comparison more obvious.

Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-08-29 15:34:57 +02:00
Vasily Gorbik 8dec6bd4ef s390/pci: avoid using strncmp with hardcoded length
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: Vasily Gorbik <gor@linux.ibm.com>
2019-08-29 15:34:57 +02:00
Vasily Gorbik 759d4899d9 s390/kaslr: reserve memory for kasan usage
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 <gor@linux.ibm.com>
2019-08-26 12:51:18 +02:00
Vasily Gorbik 9b692102d8 s390/mem_detect: provide single get_mem_detect_end
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 <gor@linux.ibm.com>
2019-08-26 12:51:18 +02:00
Vasily Gorbik 5f0917a281 s390/cmma: reuse kstrtobool for option value parsing
"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: Philipp Rudo <prudo@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-08-26 12:51:18 +02:00
Vasily Gorbik 3d64436453 s390/vdso: reuse kstrtobool for option value parsing
"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: Philipp Rudo <prudo@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-08-26 12:51:17 +02:00
Vasily Gorbik 227f52a43a s390/startup: correct command line options parsing
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 <gor@linux.ibm.com>
2019-08-26 12:51:17 +02:00
Vasily Gorbik a45425d8a5 s390/vmcp: correct early_param handling
Check "p" is not NULL before passing it to memparse, which doesn't
handle that case explicitly.

Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-08-26 12:51:17 +02:00
Vasily Gorbik 915ef7bda7 s390/numa: correct early_param handling
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: Vasily Gorbik <gor@linux.ibm.com>
2019-08-26 12:51:17 +02:00
Vasily Gorbik 22a33c7e4e s390/startup: round down "mem" option to page boundary
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: 78333d1f90 ("s390/kasan: add support for mem= kernel parameter")
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-08-21 12:58:53 +02:00
Vasily Gorbik 80ef517b01 s390/startup: adjust _sdma and _edma to page boundaries
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: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-08-21 12:58:53 +02:00
Vasily Gorbik e991e5bb11 s390/stacktrace: use common arch_stack_walk infrastructure
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 <gor@linux.ibm.com>
2019-08-21 12:58:53 +02:00
Vasily Gorbik 2c7fa8a11c s390/kasan: avoid report in get_wchan
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 <gor@linux.ibm.com>
2019-08-21 12:58:53 +02:00
Vasily Gorbik 8769f610fe s390/process: avoid potential reading of freed stack
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: d5c352cdd0 ("s390: move thread_info into task_struct")
Cc: stable@vger.kernel.org # v4.10+
Acked-by: Ilya Leoshkevich <iii@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-08-21 12:58:52 +02:00
Vasily Gorbik f45f7b5bda s390/kasan: provide uninstrumented __strlen
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 7e0d92f002 ("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: 7e0d92f002 ("s390/kasan: improve string/memory functions checks")
Acked-by: Ilya Leoshkevich <iii@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-08-21 12:58:52 +02:00
Vasily Gorbik 2e83e0eb85 s390: clean .bss before running uncompressed kernel
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: Philipp Rudo <prudo@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-08-21 12:58:52 +02:00
Vasily Gorbik 19413fe04f s390/startup: purge obsolete .gitignore patterns
sizes.h and vmlinux.scr.lds are not generated since commit 369f91c374
("s390/decompressor: rework uncompressed image info collection").

vmlinux.bin.full is not generated since commit 183ab05ff2 ("s390: get
rid of the first mb of uncompressed image").

Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-08-21 12:41:43 +02:00
Vasily Gorbik da9ed30d29 s390/startup: add initial pgm check handler
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: Ilya Leoshkevich <iii@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-08-21 12:41:43 +02:00
Vasily Gorbik 59793c5ab9 s390: move vmalloc option parsing to startup code
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: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-08-21 12:41:43 +02:00
Vasily Gorbik 739bacbf7a s390/build: use size command to perform empty .bss check
Currently empty .bss checks performed do not pay attention to "common
objects" in object files which end up in .bss section eventually.

The "size" tool is a part of binutils and since version 2.18 provides
"--common" command line option, which allows to account "common objects"
sizes in .bss section size. Utilize "size --common" to perform accurate
check that .bss section is unused. Besides that the size tool handles
object files without .bss section gracefully and doesn't require
additional objdump run.

The linux kernel requires binutils 2.20 since 4.13.

Kbuild exports OBJSIZE to reference the right size tool.

Link: http://lkml.kernel.org/r/patch-2.thread-2257a1.git-2257a1c53d4a.your-ad-here.call-01565088755-ext-5120@work.hours
Reported-and-tested-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-08-08 14:36:53 +02:00
Vasily Gorbik 7bac98707f kbuild: add OBJSIZE variable for the size tool
Define and export OBJSIZE variable for "size" tool from binutils to be
used in architecture specific Makefiles (naming the variable just "SIZE"
would be too risky). In particular this tool is useful to perform checks
that early boot code is not using bss section (which might have not been
zeroed yet or intersects with initrd or other files boot loader might
have put right after the linux kernel).

Link: http://lkml.kernel.org/r/patch-1.thread-2257a1.git-188f5a3d81d5.your-ad-here.call-01565088755-ext-5120@work.hours
Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-08-08 14:36:51 +02:00
Vasily Gorbik 24350fdadb s390: put _stext and _etext into .text section
Perf relies on _etext and _stext symbols being one of 't', 'T', 'v' or
'V'. Put them into .text section to guarantee that.

Also moves padding to page boundary inside .text which has an effect that
.text section is now padded with nops rather than 0's, which apparently
has been the initial intention for specifying 0x0700 fill expression.

Reported-by: Thomas Richter <tmricht@linux.ibm.com>
Tested-by: Thomas Richter <tmricht@linux.ibm.com>
Suggested-by: Andreas Krebbel <krebbel@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-08-06 13:58:35 +02:00
Vasily Gorbik b9f23b7376 s390/head64: cleanup unused labels
Cleanup labels in head64 some of which are not being used since git
recorded history.

Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-08-06 13:58:35 +02:00
Vasily Gorbik fd0c7435d7 s390/unwind: remove stack recursion warning
Remove pointless stack recursion on stack type ... warning, which
only confuses people. There is no way to make backchain unwinder 100%
reliable. When a task is interrupted in-between stack frame allocation
and backchain write instructions new stack frame backchain pointer is
left uninitialized (there are also sometimes additional instruction
in-between stack frame allocation and backchain write instructions due
to gcc shrink-wrapping). In attempt to unwind such stack the unwinder
would still try to use that invalid backchain value and perform all kind
of sanity checks on it to make sure we are not pointed out of stack. In
some cases that invalid backchain value would be 0 and we would falsely
treat next stackframe as pt_regs and again gprs[15] in those pt_regs
might happen to point at some address within the task's stack.

Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-08-06 13:58:35 +02:00
Vasily Gorbik 218ddd5acf s390/setup: adjust start_code of init_mm to _text
After some investigation it doesn't look like init_mm fields
start_code/end_code are used anywhere besides potentially in dump_mm for
debugging purposes. Originally the value of 0 for start_code reflected
the presence of lowcore and early boot code. But with kaslr in place
start_code/end_code range should not span over unoccupied by the code
segment memory. So, adjust init_mm start_code to point at the beginning
of the code segment like other architectures do it.

Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-08-06 13:58:34 +02:00
Vasily Gorbik 8024b5a9fc s390/mm: fix dump_pagetables top level page table walking
Since commit d1874a0c28 ("s390/mm: make the pxd_offset functions more
robust") behaviour of p4d_offset, pud_offset and pmd_offset has been
changed so that they cannot be used to iterate through top level page
table, because the index for the top level page table is now calculated
in pgd_offset. To avoid dumping the very first region/segment top level
table entry 2048 times simply iterate entry pointer like it is already
done in other page walking cases.

Fixes: d1874a0c28 ("s390/mm: make the pxd_offset functions more robust")
Reported-by: Ilya Leoshkevich <iii@linux.ibm.com>
Reviewed-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-08-06 13:58:34 +02:00
Vasily Gorbik a287a49e67 s390/protvirt: avoid memory sharing for diag 308 set/store
This reverts commit db9492cef4 ("s390/protvirt: add memory sharing for
diag 308 set/store") which due to ultravisor implementation change is
not needed after all.

Fixes: db9492cef4 ("s390/protvirt: add memory sharing for diag 308 set/store")
Reviewed-by: Janosch Frank <frankja@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-08-06 13:58:34 +02:00
Vasily Gorbik 3cdd986067 s390/zcrypt: adjust switch fall through comments for -Wimplicit-fallthrough
Silence the following warnings when built with -Wimplicit-fallthrough=3
enabled by default since 5.3-rc2:
In file included from ./include/linux/preempt.h:11,
                 from ./include/linux/spinlock.h:51,
                 from ./include/linux/mmzone.h:8,
                 from ./include/linux/gfp.h:6,
                 from ./include/linux/slab.h:15,
                 from drivers/s390/crypto/ap_queue.c:13:
drivers/s390/crypto/ap_queue.c: In function 'ap_sm_recv':
./include/linux/list.h:577:2: warning: this statement may fall through [-Wimplicit-fallthrough=]
  577 |  for (pos = list_first_entry(head, typeof(*pos), member); \
      |  ^~~
drivers/s390/crypto/ap_queue.c:147:3: note: in expansion of macro 'list_for_each_entry'
  147 |   list_for_each_entry(ap_msg, &aq->pendingq, list) {
      |   ^~~~~~~~~~~~~~~~~~~
drivers/s390/crypto/ap_queue.c:155:2: note: here
  155 |  case AP_RESPONSE_NO_PENDING_REPLY:
      |  ^~~~
drivers/s390/crypto/zcrypt_msgtype6.c: In function 'convert_response_ep11_xcrb':
drivers/s390/crypto/zcrypt_msgtype6.c:871:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
  871 |   if (msg->cprbx.cprb_ver_id == 0x04)
      |      ^
drivers/s390/crypto/zcrypt_msgtype6.c:874:2: note: here
  874 |  default: /* Unknown response type, this should NEVER EVER happen */
      |  ^~~~~~~
drivers/s390/crypto/zcrypt_msgtype6.c: In function 'convert_response_rng':
drivers/s390/crypto/zcrypt_msgtype6.c:901:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
  901 |   if (msg->cprbx.cprb_ver_id == 0x02)
      |      ^
drivers/s390/crypto/zcrypt_msgtype6.c:907:2: note: here
  907 |  default: /* Unknown response type, this should NEVER EVER happen */
      |  ^~~~~~~
drivers/s390/crypto/zcrypt_msgtype6.c: In function 'convert_response_xcrb':
drivers/s390/crypto/zcrypt_msgtype6.c:838:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
  838 |   if (msg->cprbx.cprb_ver_id == 0x02)
      |      ^
drivers/s390/crypto/zcrypt_msgtype6.c:844:2: note: here
  844 |  default: /* Unknown response type, this should NEVER EVER happen */
      |  ^~~~~~~
drivers/s390/crypto/zcrypt_msgtype6.c: In function 'convert_response_ica':
drivers/s390/crypto/zcrypt_msgtype6.c:801:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
  801 |   if (msg->cprbx.cprb_ver_id == 0x02)
      |      ^
drivers/s390/crypto/zcrypt_msgtype6.c:808:2: note: here
  808 |  default: /* Unknown response type, this should NEVER EVER happen */
      |  ^~~~~~~

Acked-by: Patrick Steuer <patrick.steuer@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-08-02 13:58:23 +02:00
Vasily Gorbik 8480657280 vfio-ccw: make vfio_ccw_async_region_ops static
Since vfio_ccw_async_region_ops is not exported and has no reason to be
globally visible make it static to avoid the following sparse warning:
drivers/s390/cio/vfio_ccw_async.c:73:30: warning: symbol 'vfio_ccw_async_region_ops' was not declared. Should it be static?

Fixes: d5afd5d135 ("vfio-ccw: add handling for async channel instructions")
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-07-29 18:05:03 +02:00
Vasily Gorbik 943dd5fa70 s390/3215: add switch fall through comment for -Wimplicit-fallthrough
Silence the following warning when built with -Wimplicit-fallthrough=3
enabled by default since 5.3-rc2:
drivers/s390/char/con3215.c: In function 'raw3215_irq':
drivers/s390/char/con3215.c:399:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
  399 |   if (dstat == 0x08)
      |      ^
drivers/s390/char/con3215.c:401:2: note: here
  401 |  case 0x04:
      |  ^~~~

Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-07-29 18:05:03 +02:00
Vasily Gorbik ffbd268506 s390/mm: make gmap_test_and_clear_dirty_pmd static
Since gmap_test_and_clear_dirty_pmd is not exported and has no reason to
be globally visible make it static to avoid the following sparse warning:
arch/s390/mm/gmap.c:2427:6: warning: symbol 'gmap_test_and_clear_dirty_pmd' was not declared. Should it be static?

Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-07-29 18:05:03 +02:00
Vasily Gorbik 1877011a35 s390/kexec: add missing include to machine_kexec_reloc.c
Include <asm/kexec.h> into machine_kexec_reloc.c to expose
arch_kexec_do_relocs declaration and avoid the following sparse warnings:
arch/s390/kernel/machine_kexec_reloc.c:4:5: warning: symbol 'arch_kexec_do_relocs' was not declared. Should it be static?
arch/s390/boot/../kernel/machine_kexec_reloc.c:4:5: warning: symbol 'arch_kexec_do_relocs' was not declared. Should it be static?

Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-07-29 18:05:03 +02:00
Vasily Gorbik 06f9895fda s390/perf: make cf_diag_csd static
Since there is really no reason for cf_diag_csd per cpu variable to be
globally visible make it static to avoid the following sparse warning:
arch/s390/kernel/perf_cpum_cf_diag.c:37:1: warning: symbol 'cf_diag_csd' was not declared. Should it be static?

Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-07-29 18:05:02 +02:00
Vasily Gorbik d25220d2f2 s390/lib: add missing include
Include <asm/xor.h> into arch/s390/lib/xor.c to expose xor_block_xc
declaration and avoid the following sparse warning:
arch/s390/lib/xor.c:128:27: warning: symbol 'xor_block_xc' was not declared. Should it be static?

Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-07-29 18:05:02 +02:00
Vasily Gorbik 868202ce15 s390/boot: add missing declarations and includes
Add __swsusp_reset_dma declaration to avoid the following sparse warnings:
arch/s390/kernel/setup.c:107:15: warning: symbol '__swsusp_reset_dma' was not declared. Should it be static?
arch/s390/boot/startup.c:52:15: warning: symbol '__swsusp_reset_dma' was not declared. Should it be static?

Add verify_facilities declaration to avoid the following sparse warning:
arch/s390/boot/als.c:105:6: warning: symbol 'verify_facilities' was not declared. Should it be static?

Include "boot.h" into arch/s390/boot/kaslr.c to expose get_random_base
function declaration and avoid the following sparse warning:
arch/s390/boot/kaslr.c:90:15: warning: symbol 'get_random_base' was not declared. Should it be static?

Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-07-29 18:05:02 +02:00
Vasily Gorbik ac7a0fcea3 s390/mm: use shared variables for sysctl range check
Since commit eec4844fae ("proc/sysctl: add shared variables for range
check") special shared variables are available for sysctl range check.
Reuse them for /proc/sys/vm/allocate_pgste proc handler.

Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-07-26 13:36:22 +02:00
Vasily Gorbik 9779048d71 s390/kasan: add bitops instrumentation
Add KASAN instrumentation of architecture-specific asm implementation
of bitops. It also covers s390 specific *_inv functions.

Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-07-23 10:46:14 +02:00
Vasily Gorbik 0a5c3c2f47 s390/bitops: make test functions return bool
Make s390/bitops test functions return bool values. That enforces return
value range to 0 and 1 and matches with asm-generic/bitops-instrumented.h
declarations as well as some other architectures implementations.

Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-07-23 10:46:03 +02:00
Vasily Gorbik 5518aed82d s390: wire up clone3 system call
Tested (64-bit and compat mode) using program from
http://lkml.kernel.org/r/20190604212930.jaaztvkent32b7d3@brauner.io
with the following:
       return syscall(__NR_clone, flags, 0, pidfd, 0, 0);
changed to:
       return syscall(__NR_clone, 0, flags, pidfd, 0, 0);
due to CLONE_BACKWARDS2.

Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-07-23 10:45:53 +02:00
Vasily Gorbik 6abe281970 s390: enable detection of kernel version from bzImage
Extend "parmarea" to include an offset of the version string, which is
stored as 8-byte big endian value.

To retrieve version string from bzImage reliably, one should check the
presence of "S390EP" ascii string at 0x10008 (available since v3.2),
then read the version string offset from 0x10428 (which has been 0
since v3.2 up to now). The string is null terminated.

Could be retrieved with the following "file" command magic (requires
file v5.34):
8 string \x02\x00\x00\x18\x60\x00\x00\x50\x02\x00\x00\x68\x60\x00\x00\x50\x40\x40\x40\x40\x40\x40\x40\x40 Linux S390
>0x10008       string          S390EP
>>0x10428      bequad          >0
>>>(0x10428.Q) string          >\0             \b, version %s

Reported-by: Petr Tesarik <ptesarik@suse.com>
Suggested-by: Petr Tesarik <ptesarik@suse.com>
Reviewed-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-07-23 10:43:50 +02:00
Vasily Gorbik 327835fb1e MAINTAINERS: update BPF JIT S390 maintainers
Ilya Leoshkevich is joining as s390 bpf maintainer. With his background
as gcc developer he would be valuable for the team and community as a
whole. Ilya, have fun!

Since there is now enough eyes on s390 bpf, relieve Christian Borntraeger,
so that he could focus on his maintainer tasks for other components.

Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Acked-by: Christian Borntraeger <borntraeger@e.ibm.com>
Acked-by: Ilya Leoshkevich <iii@linux.ibm.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-07-12 14:21:02 +02:00
Vasily Gorbik 9a15919041 s390/unwind: avoid int overflow in outside_of_stack
When current task is interrupted in-between stack frame allocation
and backchain write instructions new stack frame backchain pointer
is left uninitialized. That invalid backchain value is passed into
outside_of_stack for sanity check. Make sure int overflow does not happen
by subtracting stack_frame size from the stack "end" rather than adding
it to "random" backchain value.

Fixes: 41b0474c1b1c ("s390/unwind: introduce stack unwind API")
Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-07-11 20:40:02 +02:00
Vasily Gorbik 33177f01ca kallsyms: exclude kasan local symbols on s390
gcc asan instrumentation emits the following sequence to store frame pc
when the kernel is built with CONFIG_RELOCATABLE:
debug/vsprintf.s:
        .section        .data.rel.ro.local,"aw"
        .align  8
.LC3:
        .quad   .LASANPC4826@GOTOFF
.text
        .align  8
        .type   number, @function
number:
.LASANPC4826:

and in case reloc is issued for LASANPC label it also gets into .symtab
with the same address as actual function symbol:
$ nm -n vmlinux | grep 0000000001397150
0000000001397150 t .LASANPC4826
0000000001397150 t number

In the end kernel backtraces are almost unreadable:
[  143.748476] Call Trace:
[  143.748484] ([<000000002da3e62c>] .LASANPC2671+0x114/0x190)
[  143.748492]  [<000000002eca1a58>] .LASANPC2612+0x110/0x160
[  143.748502]  [<000000002de9d830>] print_address_description+0x80/0x3b0
[  143.748511]  [<000000002de9dd64>] __kasan_report+0x15c/0x1c8
[  143.748521]  [<000000002ecb56d4>] strrchr+0x34/0x60
[  143.748534]  [<000003ff800a9a40>] kasan_strings+0xb0/0x148 [test_kasan]
[  143.748547]  [<000003ff800a9bba>] kmalloc_tests_init+0xe2/0x528 [test_kasan]
[  143.748555]  [<000000002da2117c>] .LASANPC4069+0x354/0x748
[  143.748563]  [<000000002dbfbb16>] do_init_module+0x136/0x3b0
[  143.748571]  [<000000002dbff3f4>] .LASANPC3191+0x2164/0x25d0
[  143.748580]  [<000000002dbffc4c>] .LASANPC3196+0x184/0x1b8
[  143.748587]  [<000000002ecdf2ec>] system_call+0xd8/0x2d8

Since LASANPC labels are not even unique and get into .symtab only due
to relocs filter them out in kallsyms.

Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-07-08 02:25:59 +09:00
Vasily Gorbik 555827c28a Merge tag 'vfio-ccw-20190705' of https://git.kernel.org/pub/scm/linux/kernel/git/kvms390/vfio-ccw into features
Fix a bug introduced in the refactoring.

* tag 'vfio-ccw-20190705' of https://git.kernel.org/pub/scm/linux/kernel/git/kvms390/vfio-ccw:
  vfio-ccw: Fix the conversion of Format-0 CCWs to Format-1

Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-07-05 13:39:22 +02:00
Vasily Gorbik da17767336 s390/unwind: cleanup unused READ_ONCE_TASK_STACK
Kasan instrumentation of backchain unwinder stack reads is disabled
completely and simply uses READ_ONCE_NOCHECK now.
READ_ONCE_TASK_STACK macro is unused and could be removed.

Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-07-02 16:00:27 +02:00
Vasily Gorbik 2095574632 s390/kasan: avoid false positives during stack unwind
Avoid kasan false positive when current task is interrupted in-between
stack frame allocation and backchain write instructions leaving new stack
frame backchain invalid. In particular if backchain is 0 the unwinder
tries to read pt_regs from the stack and might hit kasan poisoned bytes,
leading to kasan "stack-out-of-bounds" report.

Disable kasan instrumentation of unwinder stack reads, since this
limitation couldn't be handled otherwise with current backchain unwinder
implementation.

Fixes: 78c98f9074 ("s390/unwind: introduce stack unwind API")
Reported-by: Julian Wiedmann <jwi@linux.ibm.com>
Tested-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-07-02 16:00:27 +02:00
Vasily Gorbik 9de3191249 Merge tag 'vfio-ccw-20190621' of https://git.kernel.org/pub/scm/linux/kernel/git/kvms390/vfio-ccw into features
Refactoring of the vfio-ccw cp handling, simplifying the
code and avoiding unneeded allocating/copying.

* tag 'vfio-ccw-20190621' of https://git.kernel.org/pub/scm/linux/kernel/git/kvms390/vfio-ccw:
  vfio-ccw: Remove copy_ccw_from_iova()
  vfio-ccw: Factor out the ccw0-to-ccw1 transition
  vfio-ccw: Copy CCW data outside length calculation
  vfio-ccw: Skip second copy of guest cp to host
  vfio-ccw: Move guest_cp storage into common struct
  s390/cio: Combine direct and indirect CCW paths
  vfio-ccw: Rearrange IDAL allocation in direct CCW
  vfio-ccw: Remove pfn_array_table
  vfio-ccw: Adjust the first IDAW outside of the nested loops
  vfio-ccw: Rearrange pfn_array and pfn_array_table arrays
  s390/cio: Use generalized CCW handler in cp_init()
  s390/cio: Generalize the TIC handler
  s390/cio: Refactor the routine that handles TIC CCWs
  s390/cio: Squash cp_free() and cp_unpin_free()

Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-06-24 17:02:28 +02:00
Vasily Gorbik b4e3133b65 s390/traps: simplify data exception handler
Simplify conditions and remove unnecessary variable in data exception
handler.

Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Reviewed-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Reviewed-by: Hendrik Brueckner <brueckner@linux.ibm.com>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-06-15 12:25:45 +02:00
Vasily Gorbik cbdaeaf050 tracing: avoid build warning with HAVE_NOP_MCOUNT
Selecting HAVE_NOP_MCOUNT enables -mnop-mcount (if gcc supports it)
and sets CC_USING_NOP_MCOUNT. Reuse __is_defined (which is suitable for
testing CC_USING_* defines) to avoid conditional compilation and fix
the following gcc 9 warning on s390:

kernel/trace/ftrace.c:2514:1: warning: ‘ftrace_code_disable’ defined
but not used [-Wunused-function]

Link: http://lkml.kernel.org/r/patch.git-1a82d13f33ac.your-ad-here.call-01559732716-ext-6629@work.hours

Fixes: 2f4df0017b ("tracing: Add -mcount-nop option support")
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2019-06-14 16:34:57 -04:00
Vasily Gorbik eec0a43ddd RAID/s390: remove invalid 'r' inline asm operand modifier
gcc silently ignores unsupported inline asm operand modifiers, effectively
turning '%r0' into '%0', but upcoming clang 9 complains about them:
lib/raid6/s390vx8.c:63:16: error: invalid operand in inline asm: 'VLM $2,$3,0,${1:r}'
        asm volatile ("VLM %2,%3,0,%r1"
                      ^

Clean up what look like a typo 'r' inline asm operand modifier usage.

Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-06-11 09:48:25 +02:00
Vasily Gorbik 0ab0d7ac20 s390/unwind: correct stack switching during unwind
Adjust conditions in on_stack function. That fixes backchain unwinder
which was unable to read pt_regs at the very bottom of the stack and
hence couldn't follow stacks (e.g. from async stack to a task stack).

Fixes: 78c98f9074 ("s390/unwind: introduce stack unwind API")
Reported-by: Julian Wiedmann <jwi@linux.ibm.com>
Reviewed-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
2019-06-07 15:20:44 +02:00
Vasily Gorbik 184c460fba s390/kasan: adapt disabled_wait usage to avoid build error
Fix the following build error when the kernel is built with CONFIG_KASAN
broken since commit 98587c2d89 ("s390: simplify disabled_wait"):

arch/s390/mm/kasan_init.c: In function 'kasan_early_panic':
arch/s390/mm/kasan_init.c:31:2: error: too many arguments to function
'disabled_wait'
   31 |  disabled_wait(0);

Fixes: 98587c2d89 ("s390: simplify disabled_wait")
Reported-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2019-05-08 15:01:09 +02:00
Vasily Gorbik 7e756f423a latent_entropy: avoid build error when plugin cflags are not set
Some architectures set up CFLAGS for linux decompressor phase from
scratch and do not include GCC_PLUGINS_CFLAGS. Since "latent_entropy"
variable declaration is generated by the plugin code itself including
linux/random.h in decompressor code then would cause a build
error. E.g. on s390:

In file included from ./include/linux/net.h:22,
                 from ./include/linux/skbuff.h:29,
                 from ./include/linux/if_ether.h:23,
                 from ./arch/s390/include/asm/diag.h:12,
                 from arch/s390/boot/startup.c:8:
./include/linux/random.h: In function 'add_latent_entropy':
./include/linux/random.h:26:39: error: 'latent_entropy' undeclared
(first use in this function); did you mean 'add_latent_entropy'?
   26 |  add_device_randomness((const void *)&latent_entropy,
      |                                       ^~~~~~~~~~~~~~
      |                                       add_latent_entropy
./include/linux/random.h:26:39: note: each undeclared identifier is
reported only once for each function it appears in

The build error is triggered by commit a80313ff91 ("s390/kernel:
introduce .dma sections") which made it into 5.2 merge window.

To address that avoid using CONFIG_GCC_PLUGIN_LATENT_ENTROPY in
favour of LATENT_ENTROPY_PLUGIN definition which is defined as a
part of gcc plugins cflags and hence reflect more accurately when gcc
plugin is active. Besides that it is also used for similar purpose in
linux/compiler-gcc.h for latent_entropy attribute definition.

Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Acked-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2019-05-08 08:15:52 +02:00
Vasily Gorbik 01eb42afb4 s390/kasan: fix strncpy_from_user kasan checks
arch/s390/lib/uaccess.c is built without kasan instrumentation. Kasan
checks are performed explicitly in copy_from_user/copy_to_user
functions. But since those functions could be inlined, calls from
files like uaccess.c with instrumentation disabled won't generate
kasan reports. This is currently the case with strncpy_from_user
function which was revealed by newly added kasan test. Avoid inlining of
copy_from_user/copy_to_user when the kernel is built with kasan support
to make sure kasan checks are fully functional.

Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2019-04-24 13:28:46 +02:00
Vasily Gorbik 35af0d469c s390: correct some inline assembly constraints
Inline assembly code changed in this patch should really use "Q"
constraint "Memory reference without index register and with short
displacement". The kernel build with kasan instrumentation enabled
might occasionally break otherwise (due to stack instrumentation).

Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2019-04-17 10:40:57 +02:00
Vasily Gorbik 093ddccb55 s390/protvirt: block kernel command line alteration
Disallow kernel command line alteration via ipl parameter block if
running in protected virtualization environment.

Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2019-04-10 17:47:22 +02:00
Vasily Gorbik db9492cef4 s390/protvirt: add memory sharing for diag 308 set/store
Add sharing of ipl parameter block for diag 308 set/store calls to allow
kvm access in protected virtualization environment.

Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2019-04-10 17:47:22 +02:00
Vasily Gorbik 5abb9351df s390/uv: introduce guest side ultravisor code
The Ultravisor Call Facility (stfle bit 158) defines an API to the
Ultravisor (UV calls), a mini hypervisor located at machine
level. With help of the Ultravisor, KVM will be able to run
"protected" VMs, special VMs whose memory and management data are
unavailable to KVM.

The protected VMs can also request services from the Ultravisor.
The guest api consists of UV calls to share and unshare memory with the
kvm hypervisor.

To enable this feature support PROTECTED_VIRTUALIZATION_GUEST kconfig
option has been introduced.

Co-developed-by: Janosch Frank <frankja@de.ibm.com>
Signed-off-by: Janosch Frank <frankja@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2019-04-10 17:47:21 +02:00
Vasily Gorbik fd184e1a8b s390: introduce .boot.preserved.data section compile time validation
Same as for .boot.data section make sure that .boot.preserved.data
sections of vmlinux and arch/s390/compressed/vmlinux match before
producing the compressed kernel image. Symbols presence, order and sizes
are cross-checked.

Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2019-04-10 17:47:12 +02:00
Vasily Gorbik 1e941d3949 s390: move ipl block to .boot.preserved.data section
.boot.preserved.data is a better fit for ipl block than .boot.data
which is discarded after init. Reusing .boot.preserved.data allows to
simplify code a little bit and avoid copying data from .boot.data to
persistent variables.

Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2019-04-10 17:47:11 +02:00
Vasily Gorbik 6d85dac2ab s390: warn about clearing als implied facilities
Add a warning about removing required architecture level set facilities
via "facilities=" command line option.

Reviewed-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2019-03-01 08:00:42 +01:00
Vasily Gorbik b5e804598d s390: allow overriding facilities via command line
Add "facilities=" command line option which allows to override
facility bits returned by stfle. The main purpose of that is debugging
aids which allows to test specific kernel behaviour depending on
specific facilities presence. It also affects CPU alternatives.

"facilities=" command line option format is comma separated list of
integer values to be additionally set or cleared (if value is starting
with "!"). Values ranges are also supported. e.g.:

facilities=!130-160,159,167-169

Reviewed-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2019-03-01 08:00:41 +01:00
Vasily Gorbik d8901f2b2d s390: clean up redundant facilities list setup
Facilities list in the lowcore is initially set up by verify_facilities
from als.c and later initializations are redundant, so cleaning them up.

Reviewed-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2019-03-01 08:00:39 +01:00
Vasily Gorbik 96d3b64b52 s390/als: remove duplicated in-place implementation of stfle
Reuse __stfle call instead of in-place implementation. __stfle is using
memcpy and memset functions but they are safe to use, since mem.S is
built with -march=z900.

Reviewed-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2019-03-01 08:00:37 +01:00
Vasily Gorbik 7e0d92f002 s390/kasan: improve string/memory functions checks
Avoid using arch specific implementations of string/memory functions
with KASAN since gcc cannot instrument asm code memory accesses and
many bugs could be missed.

Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2019-01-18 09:34:18 +01:00
Vasily Gorbik 190f056fba s390/vdso: correct vdso mapping for compat tasks
While "s390/vdso: avoid 64-bit vdso mapping for compat tasks" fixed
64-bit vdso mapping for compat tasks under gdb it introduced another
problem. "compat_mm" flag is not inherited during fork and when
31-bit process forks a child (but does not perform exec) it ends up
with 64-bit vdso. To address that, init_new_context (which is called
during fork and exec) now initialize compat_mm based on thread TIF_31BIT
flag. Later compat_mm is adjusted in arch_setup_additional_pages, which
is called during exec.

Fixes: d1befa6582 ("s390/vdso: avoid 64-bit vdso mapping for compat tasks")
Reported-by: Stefan Liebler <stli@linux.ibm.com>
Reviewed-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: <stable@vger.kernel.org> # v4.20+
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2019-01-11 17:12:02 +01:00
Vasily Gorbik 9fed920e68 s390/kasan: increase instrumented stack size to 64k
Increase kasan instrumented kernel stack size from 32k to 64k. Other
architectures seems to get away with just doubling kernel stack size under
kasan, but on s390 this appears to be not enough due to bigger frame size.
The particular pain point is kasan inlined checks (CONFIG_KASAN_INLINE
vs CONFIG_KASAN_OUTLINE). With inlined checks one particular case hitting
stack overflow is fs sync on xfs filesystem:

 #0 [9a0681e8]  704 bytes  check_usage at 34b1fc
 #1 [9a0684a8]  432 bytes  check_usage at 34c710
 #2 [9a068658]  1048 bytes  validate_chain at 35044a
 #3 [9a068a70]  312 bytes  __lock_acquire at 3559fe
 #4 [9a068ba8]  440 bytes  lock_acquire at 3576ee
 #5 [9a068d60]  104 bytes  _raw_spin_lock at 21b44e0
 #6 [9a068dc8]  1992 bytes  enqueue_entity at 2dbf72
 #7 [9a069590]  1496 bytes  enqueue_task_fair at 2df5f0
 #8 [9a069b68]  64 bytes  ttwu_do_activate at 28f438
 #9 [9a069ba8]  552 bytes  try_to_wake_up at 298c4c
 #10 [9a069dd0]  168 bytes  wake_up_worker at 23f97c
 #11 [9a069e78]  200 bytes  insert_work at 23fc2e
 #12 [9a069f40]  648 bytes  __queue_work at 2487c0
 #13 [9a06a1c8]  200 bytes  __queue_delayed_work at 24db28
 #14 [9a06a290]  248 bytes  mod_delayed_work_on at 24de84
 #15 [9a06a388]  24 bytes  kblockd_mod_delayed_work_on at 153e2a0
 #16 [9a06a3a0]  288 bytes  __blk_mq_delay_run_hw_queue at 158168c
 #17 [9a06a4c0]  192 bytes  blk_mq_run_hw_queue at 1581a3c
 #18 [9a06a580]  184 bytes  blk_mq_sched_insert_requests at 15a2192
 #19 [9a06a638]  1024 bytes  blk_mq_flush_plug_list at 1590f3a
 #20 [9a06aa38]  704 bytes  blk_flush_plug_list at 1555028
 #21 [9a06acf8]  320 bytes  schedule at 219e476
 #22 [9a06ae38]  760 bytes  schedule_timeout at 21b0aac
 #23 [9a06b130]  408 bytes  wait_for_common at 21a1706
 #24 [9a06b2c8]  360 bytes  xfs_buf_iowait at fa1540
 #25 [9a06b430]  256 bytes  __xfs_buf_submit at fadae6
 #26 [9a06b530]  264 bytes  xfs_buf_read_map at fae3f6
 #27 [9a06b638]  656 bytes  xfs_trans_read_buf_map at 10ac9a8
 #28 [9a06b8c8]  304 bytes  xfs_btree_kill_root at e72426
 #29 [9a06b9f8]  288 bytes  xfs_btree_lookup_get_block at e7bc5e
 #30 [9a06bb18]  624 bytes  xfs_btree_lookup at e7e1a6
 #31 [9a06bd88]  2664 bytes  xfs_alloc_ag_vextent_near at dfa070
 #32 [9a06c7f0]  144 bytes  xfs_alloc_ag_vextent at dff3ca
 #33 [9a06c880]  1128 bytes  xfs_alloc_vextent at e05fce
 #34 [9a06cce8]  584 bytes  xfs_bmap_btalloc at e58342
 #35 [9a06cf30]  1336 bytes  xfs_bmapi_write at e618de
 #36 [9a06d468]  776 bytes  xfs_iomap_write_allocate at ff678e
 #37 [9a06d770]  720 bytes  xfs_map_blocks at f82af8
 #38 [9a06da40]  928 bytes  xfs_writepage_map at f83cd6
 #39 [9a06dde0]  320 bytes  xfs_do_writepage at f85872
 #40 [9a06df20]  1320 bytes  write_cache_pages at 73dfe8
 #41 [9a06e448]  208 bytes  xfs_vm_writepages at f7f892
 #42 [9a06e518]  88 bytes  do_writepages at 73fe6a
 #43 [9a06e570]  872 bytes  __writeback_single_inode at a20cb6
 #44 [9a06e8d8]  664 bytes  writeback_sb_inodes at a23be2
 #45 [9a06eb70]  296 bytes  __writeback_inodes_wb at a242e0
 #46 [9a06ec98]  928 bytes  wb_writeback at a2500e
 #47 [9a06f038]  848 bytes  wb_do_writeback at a260ae
 #48 [9a06f388]  536 bytes  wb_workfn at a28228
 #49 [9a06f5a0]  1088 bytes  process_one_work at 24a234
 #50 [9a06f9e0]  1120 bytes  worker_thread at 24ba26
 #51 [9a06fe40]  104 bytes  kthread at 26545a
 #52 [9a06fea8]             kernel_thread_starter at 21b6b62

To be able to increase the stack size to 64k reuse LLILL instruction
in __switch_to function to load 64k - STACK_FRAME_OVERHEAD - __PT_SIZE
(65192) value as unsigned.

Reported-by: Benjamin Block <bblock@linux.ibm.com>
Reviewed-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2018-11-02 08:31:57 +01:00
Vasily Gorbik 5a2e1853d6 s390: avoid vmlinux segments overlap
Currently .vmlinux.info section of uncompressed vmlinux elf image is
included into the data segment and load address specified as 0. That
extends data segment to address 0 and makes "text" and "data" segments
overlap.
Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  LOAD           0x0000000000001000 0x0000000000100000 0x0000000000100000
                 0x0000000000ead03c 0x0000000000ead03c  R E    0x1000
  LOAD           0x0000000000eaf000 0x0000000000000000 0x0000000000000000
                 0x0000000001a13400 0x000000000233b520  RWE    0x1000
  NOTE           0x0000000000eae000 0x0000000000fad000 0x0000000000fad000
                 0x000000000000003c 0x000000000000003c         0x4

 Section to Segment mapping:
  Segment Sections...
   00     .text .notes
   01     .rodata __ksymtab __ksymtab_gpl __ksymtab_strings __param
   __modver .data..ro_after_init __ex_table .data __bug_table .init.text
   .exit.text .exit.data .altinstructions .altinstr_replacement
   .nospec_call_table .nospec_return_table .boot.data .init.data
   .data..percpu .bss .vmlinux.info
   02     .notes

Later when vmlinux.bin is produced from vmlinux, .vmlinux.info section
is removed. But elf vmlinux file, even though it is not bootable anymore,
used for debugging and loadable segments overlap should be avoided.

Utilize special ":NONE" phdr specification to avoid adding .vmlinux.info
into loadable data segment. Also set .vmlinux.info section type to INFO,
which allows to get a not-loadable info CONTENTS section.

Since minimal supported version of binutils 2.20 does not have
--dump-section objcopy option, make .vmlinux.info section loadable during
info.bin creation to get actual section contents.

Reported-by: Philipp Rudo <prudo@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2018-10-26 10:19:40 +02:00
Vasily Gorbik b44b136a37 s390/vdso: add missing FORCE to build targets
According to Documentation/kbuild/makefiles.txt all build targets using
if_changed should use FORCE as well. Add missing FORCE to make sure
vdso targets are rebuild properly when not just immediate prerequisites
have changed but also when build command differs.

Reviewed-by: Philipp Rudo <prudo@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2018-10-26 10:19:40 +02:00
Vasily Gorbik ef5febae15 s390/decompressor: add missing FORCE to build targets
According to Documentation/kbuild/makefiles.txt all build targets
using if_changed should use FORCE as well. Add missing FORCE to make
sure vmlinux decompressor targets are rebuild properly when not just
immediate prerequisites have changed but also when build command differs.

Reviewed-by: Philipp Rudo <prudo@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2018-10-26 10:19:40 +02:00
Vasily Gorbik cf3dbe5dac s390/kasan: support preemptible kernel build
When the kernel is built with:
CONFIG_PREEMPT=y
CONFIG_PREEMPT_COUNT=y
"stfle" function used by kasan initialization code makes additional
call to preempt_count_add/preempt_count_sub. To avoid removing kasan
instrumentation from sched code where those functions leave split stfle
function and provide __stfle variant without preemption handling to be
used by Kasan.

Reported-by: Benjamin Block <bblock@linux.ibm.com>
Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2018-10-22 08:37:45 +02:00
Vasily Gorbik 78333d1f90 s390/kasan: add support for mem= kernel parameter
Handle mem= kernel parameter in kasan to limit physical memory.

Reviewed-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2018-10-09 11:21:35 +02:00
Vasily Gorbik 12e55fa194 s390/kasan: optimize kasan vmemmap allocation
Kasan implementation now supports memory hotplug operations. For that
reason regions of initially standby memory are now skipped from
shadow mapping and are mapped/unmapped dynamically upon bringing
memory online/offline.

Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2018-10-09 11:21:34 +02:00
Vasily Gorbik 296352397d s390/kasan: avoid kasan crash with standby memory defined
Kasan early memory allocator simply chops off memory blocks from the
end of the physical memory. Reuse mem_detect info to identify actual
online memory end rather than using max_physmem_end. This allows to run
the kernel with kasan enabled and standby memory defined.

Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2018-10-09 11:21:33 +02:00
Vasily Gorbik 19733fe872 s390/head: avoid doubling early boot stack size under KASAN
Early boot stack uses predefined 4 pages of memory 0x8000-0xC000. This
stack is used to run not instumented decompressor/facilities
verification C code. It doesn't make sense to double its size when
the kernel is built with KASAN support. BOOT_STACK_ORDER is introduced
to avoid that.

Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2018-10-09 11:21:32 +02:00
Vasily Gorbik 6cad0eb561 s390/mm: improve debugfs ptdump markers walking
This allows to print multiple markers when they happened to have the
same value.

...
0x001bfffff0100000-0x001c000000000000       255M PMD I
---[ Kasan Shadow End ]---
---[ vmemmap Area ]---
0x001c000000000000-0x001c000002000000        32M PMD RW X
...

Reviewed-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2018-10-09 11:21:31 +02:00
Vasily Gorbik e006222b57 s390/mm: optimize debugfs ptdump kasan zero page walking
Kasan zero p4d/pud/pmd/pte are always filled in with corresponding
kasan zero entries. Walking kasan zero page backed area is time
consuming and unnecessary. When kasan zero p4d/pud/pmd is encountered,
it eventually points to the kasan zero page always with the same
attributes and nothing but it, therefore zero p4d/pud/pmd could
be jumped over.

Also adds a space between address range and pages number to separate
them from each other when pages number is huge.

0x0018000000000000-0x0018000010000000       256M PMD RW X
0x0018000010000000-0x001bfffff0000000 1073741312M PTE RO X
0x001bfffff0000000-0x001bfffff0001000         4K PTE RW X

Reviewed-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2018-10-09 11:21:30 +02:00
Vasily Gorbik 5dff03813f s390/kasan: add option for 4-level paging support
By default 3-level paging is used when the kernel is compiled with
kasan support. Add 4-level paging option to support systems with more
then 3TB of physical memory and to cover 4-level paging specific code
with kasan as well.

Reviewed-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2018-10-09 11:21:29 +02:00
Vasily Gorbik 135ff16393 s390/kasan: free early identity mapping structures
Kasan initialization code is changed to populate persistent shadow
first, save allocator position into pgalloc_freeable and proceed with
early identity mapping creation. This way early identity mapping paging
structures could be freed at once after switching to swapper_pg_dir
when early identity mapping is not needed anymore.

Reviewed-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2018-10-09 11:21:29 +02:00
Vasily Gorbik 5e78596329 s390/kasan: enable stack and global variables access checks
By defining KASAN_SHADOW_OFFSET in Kconfig stack and global variables
memory access check instrumentation is enabled. gcc version 4.9.2 or
newer is also required.

Reviewed-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2018-10-09 11:21:28 +02:00
Vasily Gorbik f4f0d32bfb s390/dumpstack: disable __dump_trace kasan instrumentation
Walking async_stack produces false positives. Disable __dump_trace
function instrumentation for now.

Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2018-10-09 11:21:27 +02:00
Vasily Gorbik ac1256f826 s390/kasan: reipl and kexec support
Some functions from both arch/s390/kernel/ipl.c and
arch/s390/kernel/machine_kexec.c are called without DAT enabled
(or with and without DAT enabled code paths). There is no easy way
to partially disable kasan for those files without a substantial
rework. Disable kasan for both files for now.

To avoid disabling kasan for arch/s390/kernel/diag.c DAT flag is
enabled in diag308 call. pcpu_delegate which disables DAT is marked
with __no_sanitize_address to disable instrumentation for that one
function.

Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2018-10-09 11:21:27 +02:00
Vasily Gorbik 9e8df6daed s390/smp: kasan stack instrumentation support
smp_start_secondary function is called without DAT enabled. To avoid
disabling kasan instrumentation for entire arch/s390/kernel/smp.c
smp_start_secondary has been split in 2 parts. smp_start_secondary has
instrumentation disabled, it does minimal setup and enables DAT. Then
instrumentated __smp_start_secondary is called to do the rest.

__load_psw_mask function instrumentation has been disabled as well
to be able to call it from smp_start_secondary.

Reviewed-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2018-10-09 11:21:26 +02:00
Vasily Gorbik dde709d136 compiler: introduce __no_sanitize_address_or_inline
Due to conflict between kasan instrumentation and inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67368 functions which are
defined as inline could not be called from functions defined with
__no_sanitize_address.

Introduce __no_sanitize_address_or_inline which would expand to
__no_sanitize_address when the kernel is built with kasan support and
to inline otherwise. This helps to avoid disabling kasan
instrumentation for entire files.

Reviewed-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2018-10-09 11:21:25 +02:00
Vasily Gorbik d58106c3ec s390/kasan: use noexec and large pages
To lower memory footprint and speed up kasan initialisation detect
EDAT availability and use large pages if possible. As we know how
much memory is needed for initialisation, another simplistic large
page allocator is introduced to avoid memory fragmentation.

Since facilities list is retrieved anyhow, detect noexec support and
adjust pages attributes. Handle noexec kernel option to avoid inconsistent
kasan shadow memory pages flags.

Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2018-10-09 11:21:24 +02:00
Vasily Gorbik 793213a82d s390/kasan: dynamic shadow mem allocation for modules
Move from modules area entire shadow memory preallocation to dynamic
allocation per module load.

This behaivior has been introduced for x86 with bebf56a1b: "This patch
also forces module_alloc() to return 8*PAGE_SIZE aligned address making
shadow memory handling ( kasan_module_alloc()/kasan_module_free() )
more simple. Such alignment guarantees that each shadow page backing
modules address space correspond to only one module_alloc() allocation"

Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2018-10-09 11:21:23 +02:00
Vasily Gorbik 0dac8f6bc3 s390/mm: add kasan shadow to the debugfs pgtable dump
This change adds address space markers for kasan shadow memory.

Reviewed-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2018-10-09 11:21:22 +02:00
Vasily Gorbik b6cbe3e8bd s390/kasan: avoid user access code instrumentation
Kasan instrumentation adds "store" check for variables marked as
modified by inline assembly. With user pointers containing addresses
from another address space this produces false positives.

static inline unsigned long clear_user_xc(void __user *to, ...)
{
	asm volatile(
	...
	: "+a" (to) ...

User space access functions are wrapped by manually instrumented
functions in kasan common code, which should be sufficient to catch
errors. So, we just disable uaccess.o instrumentation altogether.

Reviewed-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2018-10-09 11:21:21 +02:00
Vasily Gorbik 7fef92ccad s390/kasan: double the stack size
Kasan stack instrumentation pads stack variables with redzones, which
increases stack frames size significantly. Stack sizes are increased
from 16k to 32k in the code, as well as for the kernel stack overflow
detection option (CHECK_STACK).

Reviewed-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2018-10-09 11:21:21 +02:00
Vasily Gorbik 42db5ed860 s390/kasan: add initialization code and enable it
Kasan needs 1/8 of kernel virtual address space to be reserved as the
shadow area. And eventually it requires the shadow memory offset to be
known at compile time (passed to the compiler when full instrumentation
is enabled).  Any value picked as the shadow area offset for 3-level
paging would eat up identity mapping on 4-level paging (with 1PB
shadow area size). So, the kernel sticks to 3-level paging when kasan
is enabled. 3TB border is picked as the shadow offset.  The memory
layout is adjusted so, that physical memory border does not exceed
KASAN_SHADOW_START and vmemmap does not go below KASAN_SHADOW_END.

Due to the fact that on s390 paging is set up very late and to cover
more code with kasan instrumentation, temporary identity mapping and
final shadow memory are set up early. The shadow memory mapping is
later carried over to init_mm.pgd during paging_init.

For the needs of paging structures allocation and shadow memory
population a primitive allocator is used, which simply chops off
memory blocks from the end of the physical memory.

Kasan currenty doesn't track vmemmap and vmalloc areas.

Current memory layout (for 3-level paging, 2GB physical memory).

---[ Identity Mapping ]---
0x0000000000000000-0x0000000000100000
---[ Kernel Image Start ]---
0x0000000000100000-0x0000000002b00000
---[ Kernel Image End ]---
0x0000000002b00000-0x0000000080000000        2G <- physical memory border
0x0000000080000000-0x0000030000000000     3070G PUD I
---[ Kasan Shadow Start ]---
0x0000030000000000-0x0000030010000000      256M PMD RW X  <- shadow for 2G memory
0x0000030010000000-0x0000037ff0000000   523776M PTE RO NX <- kasan zero ro page
0x0000037ff0000000-0x0000038000000000      256M PMD RW X  <- shadow for 2G modules
---[ Kasan Shadow End ]---
0x0000038000000000-0x000003d100000000      324G PUD I
---[ vmemmap Area ]---
0x000003d100000000-0x000003e080000000
---[ vmalloc Area ]---
0x000003e080000000-0x000003ff80000000
---[ Modules Area ]---
0x000003ff80000000-0x0000040000000000        2G

Acked-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2018-10-09 11:21:20 +02:00