Create a separate C header for DFI VMCOREINFO to separate
independent things and make it more readable.
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Replace magic values with descriptive names to improve readability.
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
To prevent segmentation faults when the function dfi_mem_phys_read() is
given invalid parameters, check that the given memory range falls within
a known physical memory chunk, just like it is done for dfi_mem_virt_read().
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The new name describes the purpose of the function better and
emphasizes its difference with the function dfi_mem_phys_read().
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Always use the function dfi_mem_read_rc() which verifies that the given
address and size fall within a valid memory chunk. We cannot trust
user's input.
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The function dfi_mem_chunk_virt_add() is used only internally and should
not be exported to prevent misuse.
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The keyword extern is redundant for function declarations in C headers.
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Set stage3_parms.envblk_len to 0, if add_envblk is false.
This fixes segmentation fault when performing job with
not defined zIPL environment (e.g. installing SCSI dump)
Signed-off-by: Eduard Shishkin <edward6@linux.ibm.com>
Tested-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
PCI and crypto devices defined using the IBM Z Dynamic Partition Manager
(DPM) will start in an offline/unconfigured state that requires manual
intervention before the associated Linux function can be used. This
results for example in PCI networking interfaces being unavailable in a
distribution installer system.
Fix this by providing a udev rule and initial RAM-disk logic that
automatically enables PCI and crypto devices either during boot, or when
they are defined at run-time. This processing can be suppressed by
specifying the "rd.zdev=no-auto" parameter on the kernel command line.
Auto-configuration is limited to Linux running in DPM LPARs because
PCI-functions and crypto devices defined by DPM are always intended for
use by a single LPAR only.
For Linux running in classic-mode LPARs or virtual machines, leaving PCI
and crypto devices in an offline state may be useful to allow defining a
device as available to multiple systems, where only the system that
intends to make use of the device should enable it.
Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Reviewed-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add an internal tool intended to be used by udev rules to determine
zdev and hypervisor related system information in key=value format.
Supported keys are:
ZDEV_NEST_LEVEL=n
Virtualization nesting level of running system
ZDEV_HYPERVISOR_<n>=LPAR|z/VM|KVM/Linux
Type of hypervisor that provides virtualization at nesting level <n>
ZDEV_IS_DPM=0|1
Indicator if top-level LPAR is managed by Dynamic Partition Manager
ZDEV_NO_AUTO=0|1
Indicator if auto-configuration is requested
Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Reviewed-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
zgetdump is for analyzing VM coredumps and not user space coredumps therefore
return an error in case of a user space coredump.
Reviewed-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add new tool named 'sclpdbf'. This script displays the contents of
s390dbf sclp debug logs in human-readable format.
Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Reviewed-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Added a tool to operate with zIPL environment, currently
installed in the boot record. All modifying operations result
in atomic update of the installed environment block, bypassing
the file system driver.
Operations currently supported by zIPL environment editor:
. set/unset environment variables,
. print/reset environment
Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Eduard Shishkin <edward6@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
from disk.c to a dedicated source file fs-map.c, so that the new
zipl-editenv tool will be also able to use it.
Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Eduard Shishkin <edward6@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Before starting the kernel:
1. parse environment block (if any) and create a hash table
of all found pairs (NAME, VALUE);
2. scan the command line, which already contains extra-parameters
(if any), and for each found ${NAME} replace it with VALUE, as
found in the hash table by NAME.
Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Eduard Shishkin <edward6@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
When installing a boot record for "ipl" and "menu" job, always add
an environment block as a boot component located in bootmap file
at offset alinged on file system block size boundary. When adding,
first try to import environment from a file at location specified
by newly introduced "--environment" zipl option, or by default at
"/etc/ziplenv". If nothing was imported, then add a blank environment
block. Optionally print the content of the environment block.
Store environment block size and address (as of boot component) in
stage3_parms.
Change interface of add_ipl_program(): add 2 additional arguments:
a pointer to bootmap file name and a predicate indicating if we
need to add environment block as a boot component.
Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Eduard Shishkin <edward6@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Provide helper functions disk_write_block_buffer_align()
and add_component_buffer_align() to align offset of the record
on specified block size boundary and to save the offset, where
the record was made at.
This will be used by a later patch.
Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Eduard Shishkin <edward6@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
. expand interface of disk_get_blocklist_from_file() to get
block pointers for a specific range of data within a file.
. provide a helper function add_component_file_range() to add a
specific range of data within a file as a boot component.
This will be used by a later patch.
Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Eduard Shishkin <edward6@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
This fixes the following Valgrind finding:
==28040== Syscall param rt_sigaction(act->sa_flags) points to uninitialised byte(s)
==28040== at 0x48C98B0: __libc_sigaction (sigaction.c:58)
==28040== by 0x10D507: sig_handler_init (zgetdump.c:58)
==28040== by 0x10D507: main (zgetdump.c:179)
==28040== Address 0x1ffefffc84 is on thread 1's stack
==28040== in frame #0, created by __libc_sigaction (sigaction.c:43)
Reviewed-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Fix the following incorrect help text line:
-T, --file-timeout (null) Stop reading file after SEC seconds
Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Sanity check ELF notes descriptor size before reading it. This prevents
stack buffer overflows in case a dump contains invalid ELF notes.
Instead of reading a note's descriptor into a temporary buffer on stack,
read it directly into the buffer given to nt_read() but also provide
a maximum length of the given buffer to nt_read() in order to prevent
overflows.
This problem was found with valgrind and AFL fuzzing + ASAN.
AFL + ASAN findings:
[root@t83lp49 s390-tools]# ./zdump/zgetdump -iVVVVV ~/zgetdump-fuzzing/findings/crashes/id\:000008\,sig\:06\,src\:000007\,op\:arith8\,pos\:67\,val\:+3
TRACE: DFI initialization
DEBUG: DFI trying s390tape
DEBUG: DFI s390tape returned with rc -19
DEBUG: DFI trying devmem
DEBUG: DFI devmem returned with rc -19
DEBUG: DFI trying s390mv_ext
DEBUG: DFI s390mv_ext returned with rc -19
DEBUG: DFI trying s390mv
DEBUG: DFI s390mv returned with rc -19
DEBUG: DFI trying s390_ext
DEBUG: DFI S390 extended initialization
DEBUG: DFI s390_ext returned with rc -19
DEBUG: DFI trying s390
DEBUG: DFI S390 initialization
DEBUG: DFI s390 returned with rc -19
DEBUG: DFI trying lkcd
DEBUG: DFI lkcd returned with rc -19
DEBUG: DFI trying elf
DEBUG: DFI ELF initialization
DEBUG: DFI ELF e_phnum 11
DEBUG: DFI ELF p_type[0] 0x4
DEBUG: DFI ELF n_type 0x0
AddressSanitizer:DEADLYSIGNAL
=================================================================
==208548==ERROR: AddressSanitizer: stack-overflow on address 0x03ffef05d000 (pc 0x0000010051b0 bp 0x03fff107dc40 sp 0x03ffef05dac8 T0)
#0 0x10051b0 (/root/s390-tools/zdump/zgetdump+0x10051b0)
SUMMARY: AddressSanitizer: stack-overflow (/root/s390-tools/zdump/zgetdump+0x10051b0)
==208548==ABORTING
valgrind findings:
==56423== Source and destination overlap in memcpy(0x4a86d38, 0x4a875e0, 4096)
==56423== at 0x4839F86: memcpy (in /usr/lib/s390x-linux-gnu/valgrind/vgpreload_memcheck-s390x-linux.so)
==56423== by 0x114253: memcpy (string_fortified.h:34)
==56423== by 0x114253: nt_read (dfi_elf.c:95)
==56423== by 0x1145FF: nt_s390_prefix_read (dfi_elf.c:195)
==56423== by 0x1145FF: pt_notes_add (dfi_elf.c:259)
==56423== by 0x1145FF: dfi_elf_init (dfi_elf.c:326)
==56423== by 0x112A57: dfi_init (dfi.c:1212)
==56423== by 0x10D663: do_dump_info (zgetdump.c:127)
==56423== by 0x10D663: main (zgetdump.c:182)
==56423==
==56423== Invalid write of size 8
==56423== at 0x4839E28: memcpy (in /usr/lib/s390x-linux-gnu/valgrind/vgpreload_memcheck-s390x-linux.so)
==56423== by 0x114253: memcpy (string_fortified.h:34)
==56423== by 0x114253: nt_read (dfi_elf.c:95)
==56423== by 0x1145FF: nt_s390_prefix_read (dfi_elf.c:195)
==56423== by 0x1145FF: pt_notes_add (dfi_elf.c:259)
==56423== by 0x1145FF: dfi_elf_init (dfi_elf.c:326)
==56423== by 0x112A57: dfi_init (dfi.c:1212)
==56423== by 0x10D663: do_dump_info (zgetdump.c:127)
==56423== by 0x10D663: main (zgetdump.c:182)
==56423== Address 0x4a86ee0 is 0 bytes after a block of size 912 alloc'd
==56423== at 0x483675E: calloc (in /usr/lib/s390x-linux-gnu/valgrind/vgpreload_memcheck-s390x-linux.so)
==56423== by 0x10E71D: zg_alloc (zg.c:93)
==56423== by 0x114793: nt_prstatus_read (dfi_elf.c:123)
==56423== by 0x114793: pt_notes_add (dfi_elf.c:234)
==56423== by 0x114793: dfi_elf_init (dfi_elf.c:326)
==56423== by 0x112A57: dfi_init (dfi.c:1212)
==56423== by 0x10D663: do_dump_info (zgetdump.c:127)
==56423== by 0x10D663: main (zgetdump.c:182)
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Suggested-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reported-by: Steffen Eiden <seiden@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Had a confusing decoded trace record:
Timestamp : ...
Area : SCSI
...
Tag : rsl_err
...
SCSI result : 0x00000002
SCSI opcode : 1a...
FCP rsp inf cod: 0x00
FCP rsp IU : 00000000 00000000 00000a02 000000ff
00000012 00000000
^^
and was wondering where that sense data would be or if the
corresponding PAY record "fcp_riu" was lost due to trace area wrapping.
So the fix here adds the following two lines to the same trace record:
FCP rsp IU len : 42
FCP rsp IU all : record not available anymore.
Similarly, the following LUN reset Task Management Function response
was missing the last two lines regarding the full FCP response IU
and its optional part with the FCP response info:
Timestamp : ...
Area : SCSI
...
Tag : lr_okay
...
FCP rsp inf cod: 0x00
FCP rsp IU : 00000000 00000000 00000100 00000000
00000000 00000008
^^
FCP rsp IU len : 32
FCP rsp IU all : record not available anymore.
As of today, depending on the kernel version we have
either fcp_sns or fcp_riu PAY trace records. See Linux kernel v4.14 commit
12c3e5754c80 ("scsi: zfcp: fix payload with full FCP_RSP IU in SCSI trace
records").
Always print non-zero payload length independent of payload type.
Actually this also fixes a regression for wrapped away fcp_sns.
If there is no fcp_sns it either wrapped away or it's a kernel with fcp_riu.
Only print fcp_riu if it contains more content than the preceding
unconditional fixed-size field "FCP rsp IU".
Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Reviewed-by: Fedor Loshakov <loshakov@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
If the while loop in mem_chunks_add_ext() is never executed, then
the stack variable containing the dump segment header will never be
initialized.
clang's static code analyzer reports the following problem:
$ make CC="clang --analyze" -C zdump
dfi_s390.c:157:6: warning: Branch condition evaluates to a garbage value [core.uninitialized.Branch]
if (!dump_segm.stop_marker)
^~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Reported-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Use util_log from libutil to output various log messages that can be helpful
during problem analysis.
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Replace the incorrect %d format specifier with %u one for unsigned integer
types.
This issue was found with AFL fuzzing.
$ ./zdump/zgetdump -i ~/input.bin
General dump info:
Dump format........: s390
Version............: -2147483647
System arch........: s390x (64 bit)
CPU count (online).: 32768
Dump memory range..: 1 MB
Memory map:
0000000000000000 - 00000000000f423f (1 MB)
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
We found situations, where the debug commands from dbginfo.sh
did overwrite some debug files (e.g. OSA s390dbf) - so we change
the collection order
Signed-off-by: Joern Siglen <siglen@de.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Before reading data in dfi_vmcoreinfo_init(), check the validity
of the memory range. Otherwise this can result in a segmentation fault when
zgetdump is given a very small dump, e.g. S390 DASD single-volume dump of
size 0x10 bytes.
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Before reading data in os_info_get(), check the validity of the memory
range. Otherwise this can result in a segmentation fault when zgetdump is
given a very small dump, e.g. S390 DASD single-volume dump of size 0x10
bytes.
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Before reading data at addresses 0x10418 and 0x10420 in kdump_init(),
validate the validity of the memory range. Otherwise this can result in
a segmentation fault when zgetdump is given a very small dump, e.g.
S390 DASD single-volume dump of size 0x1000 bytes.
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The dfi_vmcoreinfo_init() function might be called on a dump of a non-ELF
format because the DFI goes through all supported dump formats when first
trying to identify of what dump format the given input is. Therefore,
we must be very careful in interpreting read data and ensure that it
makes sense before accessing or using it.
This commit prevents a potential overflow of a stack buffer in
dfi_vmcoreinfo_init() if note.n_namesz is bigger than the stack buffer.
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
- adding new print function for simpler output customizing
- consolidate some output files
- sync structures and use of checks
- some formatting updates
Signed-off-by: Joern Siglen <siglen@de.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The function mem_chunks_add_ext() allocates but does not release memory
if it encounters unexpected errors during dump segment reading.
Allocate memory passed to dfi_mem_chunk_add() right before calling
the function. This way there is no need for a cleanup anymore.
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Reviewed-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reported-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
- clenaup outdated kernel - we no longer have 2.x kenrel in support
- add timeout on command excution - ensure to not miss all data for a
single command to hang
Signed-off-by: Joern Siglen <siglen@de.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
When integrity support is enabled for a LUKS2 volume, then the LUKS2
volume key may include the integrity key concatenated to the secure key
(dependent on the integrity type).
Get the integrity key size from the LUKS2 header (if integrity support
is enabled) and calculate the size of the secure key when performing
operations with the secure key only.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
According to the ELF specification, the file size of a PT_LOAD
memory segment might be less than its memory size. In that case,
the remaining bytes must be filled with zeros. The ELF DFI implementation
didn't handle this case correctly. Such ELF core files might be produced
by the makedumpfile tool.
From elf.5 man page:
------------------------------------------------------
PT_LOAD
The array element specifies a loadable segment,
described by p_filesz and p_memsz. The bytes
from the file are mapped to the beginning of the
memory segment. If the segment's memory size
p_memsz is larger than the file size p_filesz,
the "extra" bytes are defined to hold the value
0 and to follow the segment's initialized area.
The file size may not be larger than the memory
size. Loadable segment entries in the program
header table appear in ascending order, sorted
on the p_vaddr member.
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Before attempting to read ELF program headers, the file must be positioned
at the offset of the first program header as specified in the ELF header.
Furthermore, read all ELF program headers with one call to zg_read(). This
has the advantage of not having to restore the file offset every time
after it is changed in pt_notes_add() and other functions which need to
read the same file as well.
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
