With parameter OSSL_ASYM_CIPHER_PARAM_IMPLICIT_REJECTION one can enable or
disable the implicit rejection mechanism for RSA PKCS#1 v1.5 decryption.
For the default provider, this is enabled by default.
We do not support implicit rejection so far, so disable it for the
default provider operation context when the key contains an RSA secure key,
and reject to set it to anything else then 0 (disabled).
See OpenSSL commit 5ab3ec1bb1
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Since OpenSSL 3.1 a new RSA-PSS salt length constant exists to select
the maximum possible salt length based on the RSA-PSS parameters and the
digest used: OSSL_PKEY_RSA_PSS_SALT_LEN_AUTO_DIGEST_MAX
This is the default salt length when no other salt length is set by
the caller.
In contrast to OSSL_PKEY_RSA_PSS_SALT_LEN_MAX, OSSL_PKEY_RSA_PSS_SALT_LEN_AUTO_DIGEST_MAX
also ensures that the resulting salt length is not larger than the used
digest size. The salt length calculated with OSSL_PKEY_RSA_PSS_SALT_LEN_MAX
may be larger than the digest size, dependent on the RSA-PSS parameters.
FIPS 186-4 section 5 "The RSA Digital Signature Algorithm", subsection
5.5 "PKCS #1" says: "For RSASSA-PSS […] the length (in bytes) of the
salt (sLen) shall satisfy 0 <= sLen <= hLen, where hLen is the length of
the hash function output block (in bytes)."
See OpenSSL commit 6c73ca4a2f
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
With parameter OSSL_SIGNATURE_PARAM_NONCE_TYPE one can choose to generate
a deterministic signature, i.e. using a deterministic nonce K.
We do not support that so far, so reject to set the nonce type to
anything other than 0 (random nonce K).
See OpenSSL commit f3090fc710
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Fix the improper order of resource releasing resulted in failed umount
Do umount after closing (not before)
Fixes: f7d2339 (zipl: List-Directed IPL from ECKD DASD)
Reported-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Tested-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Eduard Shishkin <edward6@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
The library libvmdump is written in C++ and uses exception handling
and class inheritance. The tools vmur and vmconnect are compiled using
the C++ compiler for linking with the libvmdump library.
With integration of vmdump file support into the zgetdump tool and
the removal of vmur vmdump file conversion support there is no need
anymore the vmconvert tool.
With removal of the tool vmconvert, the libvmdump library written in C++
has no more user and can be deleted.
Remove the vmconvert command from the zgetdump man page.
Remove the directories libvmdump and vmconvert and adjust the Makefile.
Signed-off-by: Thomas Richter <tmricht@linux.ibm.com>
Suggested-by: Jan Hoeppner <hoeppner@linux.ibm.com>
Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Remove option -c for implicit dump file conversion from vmdump format
to lkcd format. If option -c is specified, an error message
is printed and the program terminates. A hint to the new conversion
tool zgetdump is shown. Option -c is not listed in the help text.
The man page is also updated to reflect this change.
With zgetdump tool now supporting vmdump file format there is no need to
convert a vmdump file while extracting it from the reader device.
Use commands
1. vmur rec <spool-id> VMDUMP_FILE
2. zgetdump VMDUMP_FILE ELF_FILE
to extract a vmdump file from the reader and convert it to elf format.
Note to Maintainer:
The rename of file vmur.cpp to vmur.c triggers the pre-commit
checking of git-format-clang. This checking fails. This is intended.
The patch shows the changes for this line item.
The pre-commit checking fails on many, many changes not touched
for changed by this patch.
The pre-commit failure should be fixed with a follow-on patch.
Suggested-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Thomas Richter <tmricht@linux.ibm.com>
Acked-by: Jan Hoeppner <hoeppner@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Add support for vmdump 64big format to the zgetdump utility.
The result is an elf file suitable for tool crash.
This patch adds file dfi_vmdump.c to handle conversion from
z/VM vmdump format to the internal memory representation of this tool.
Therefore both output formats elf and s390 are supported as target
of the conversion.
The vmdump file formats 32bit and 64bit are not supported anymore.
They have been obsolete since CP version 5.1 (end of service since
30-Sep-2009).
Vector register set is not part of a vmdump file and can not be
displayed.
Output before:
# zgetdump ~/vmdump-0383
zgetdump: No valid dump found on "/root/vmdump-0383"
#
Output after:
# ./zgetdump ~/vmdump-0383 ~/vmdump-0383.elf
Format Info:
Source: vmdump
Target: elf
Copying dump:
00000000 / 00000379 MB
00000379 / 00000379 MB
Success: Dump has been copied
# file ~/vmdump-0383.elf
/root/vmdump-0383.elf: ELF 64-bit MSB core file, IBM S/390, version 1 \
.... (SYSV), SVR4-style, from 'vmlinux'
#
# ./zgetdump -i ~/vmdump-0383
General dump info:
Dump format........: vmdump
Version............: 2
UTS node name......: s8360046.lnxne.boe
UTS kernel release.: 6.1.0-rc2-d-perf+
UTS kernel version.: #1 SMP Fri Oct 28 09:42:13 CEST 2022
System arch........: s390x (64 bit)
CPU count (online).: 2
CPU count (real)...: 2
Dump memory range..: 2048 MB
Memory map:
0000000000000000 - 000000007fffffff (2048 MB)
#
Signed-off-by: Thomas Richter <tmricht@linux.ibm.com>
Reviewed-by: Mikhail Zaslonko <zaslonko@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
The `.check_dep_zgetdump` file is used to cache the result of the
dependency checks and should not be used as input for linking or
anything else. Let's add it as dependency for the objects file. This
shouldn't cause any problems since the Makefile rule for object files is
defined in `common.mak` as follows:
%.o: %.c
$(CC) $(ALL_CPPFLAGS) $(ALL_CFLAGS) -c $< -o $@
Fixes: https://github.com/ibm-s390-linux/s390-tools/issues/147
Fixes: 8d8d5e9746 ("zdump: Fix Makefile dependencies")
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com>
Signed-off-by: Jan Hoeppner <hoeppner@linux.ibm.com>
Enforce that the first glib.h include is done via glib-helper.h for libpv
so that glib version checks are in place.
Change zdump and pvattest such that they never include glibstuff before
libpv/glib-helper.h
Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Since coreutils v9.1 commit 8f31074cb ("chown: warn about USER.GROUP")
chown utility now warns about using of wrong separator for USER and
GROUP options. This leads to warnings during intall step in ziomon:
$ make install
INSTALL ziomon
SED ziomon/install
chown: warning: '.' should be ':': ‘root.root’
SED ziomon/install
chown: warning: '.' should be ':': ‘root.root’
SED ziomon/install
chown: warning: '.' should be ':': ‘root.root’
To fix those warnings use ':' as separator instead of '.'. With this
patch applied those warnings are no longer present.
Signed-off-by: Fedor Loshakov <loshakov@linux.ibm.com>
Reviewed-by: Steffen Maier <maier@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
As on space problems the packing may fail, incomplete tgz are send.
Today no evidence for this is in dbginfo.log, packed upfront into the tgz.
This update helps to identify space related corruption of tgz files.
Reviewed-by: Mario Held <mario.held@de.ibm.com>
Signed-off-by: Joern Siglen <siglen@de.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
When the kernel is build with CONFIG_NVME_MULTIPATH enabled and an NVMe
where the driver exposes its controller separately is used, chreipl node
on a mount point of the NVMe fails. The failure occurs because chreipl
tries to get the function_id from the NVMe's nvmeXnY block device via
the path '/sys/block/nvmeXnY/device/device/function_id' which does not
exist.
The underlying problem is that with NVMe multipath support the PCI
function is not associated directly with a particular NVMe namespace but
instead with the entire NVMe device which may host multiple NVMe
namespaces. The correct way to get from the block device to the
underlying PCI device and its function ID is then to extract the device
name i.e. the 'nvmeX' part from 'nvmeXnY' and use that to get the
function ID via '/sys/class/nvme/nvme<X>/device/function_id'.
Fixes: 0472b5ea5c ("ipl-tools: Add nvme device support to lsreipl/chreipl")
Reviewed-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
xxd has vim-common as a dependency. We can avoid that by using od
instead which is from coreutils.
While at it, add the require_command function from the
pvattest-info script to the pvextract-hdr script and use it.
Suggested-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Reviewed-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Fix issue in the lszdev command where column names if using the --pairs
command line switch can contain characters that are not allowed to be
used as variable names in a shell environment.
Replace bad characters in column names by an underscore if the --shell
command line switch is specified along with the --pairs switch.
The additional --shell switch mimics what is already available in the
lsblk command and thus it shall be used along with the --pairs switch.
Signed-off-by: Daniel S. Haischt <modean@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
The proc_sum_t struct is defined with the packed attribute and
produces the following compile warning:
mon_procd.c: In function ‘read_cpu’:
mon_procd.c:351:27: warning: taking address of packed member of ‘struct proc_sum_t’ may result in an unaligned pointer value [-Waddress-of-packed-member]
351 | cal_cpu(&cpudata, &proc_sum.cpu);
| ^~~~~~~~~~~~~
Silence the warning with -Wno-address-of-packed-member compile flag
since the struct is required to be as is.
Reviewed-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
The struct scsi_dump_sb is defined with the __packed attribute and
produces the following compile warning in zfcpdump:
zfcpdump_part.c: In function ‘csum_update’:
zfcpdump_part.c:125:41: warning: taking address of packed member of ‘struct scsi_dump_sb’ may result in an unaligned pointer value [-Waddress-of-packed-member]
125 | dump_sb.csum_size, &dump_sb.csum)) {
| ^~~~~~~~~~~~~
However, all members are of the same size and the __packed attribute is
unnecessary. Remove the attribute to get rid of the warning.
Add assertion to ensure correct size of the struct during compile time.
Reviewed-by: Steffen Eiden <seiden@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
The 'unistd.h' header was missing. Under some circumstances the
-D_GNU_SOURCE gcc flag does not trigger including that file.
Therefore, explicitly include this file here.
Fixes: e1aec24e84 ("libutil: introduce util_lockfile")
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
mdevctl has been updated to use /usr/lib/mdevctl/scripts.d/callouts/
instead of /etc/mdevctl.d/scripts.d/callouts/. The /etc location
is considered deprecated, meaning mdevctl will also look at that
location for now but might eventually stop looking in /etc for
callout scripts.
Based on that, update the installation location for the ap-check
callout. However, because older versions of mdevctl will still
only look in /etc, let's also put a wrapper script in /etc for now
to provide backward compatibility, and plan to remove it at a
later time.
Link: df6bb57429
Fixes: https://github.com/ibm-s390-linux/s390-tools/issues/139
Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com>
Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Commit ae7217806b ("common.mak: remove `LINK` and `LINKXX`") changed
the LINK and LINKXX definition to ensure that the same compiler is used
for compilation and linking when specified with CC= (or CXX=
respectively) on the commandline.
However, the commit also removed the pretty print for both commands. Add
the pretty print back in and use the already defined $(CC) and $(CXX)
variables to preserve the original change.
Fixes: ae7217806b ("common.mak: remove `LINK` and `LINKXX`")
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Check the dump provided sizes for reasonableness. This avoids that a
corrupted dump leads to allocation of large buffers on the heap.
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Steffen Eiden <seiden@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Verify that the size is large enough before doing the mmap. Otherwise
this can result in a SIGBUS signal if there is an attempt to access a
page that lies beyond the end of the mapped file (see `man 2 mmap`).
Fixes: 8fa1b5a00b ("zdump: dfi: add support to read Protected Virtualization dumps")
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Steffen Eiden <seiden@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Corrupted dumps might have invalid page states. Therefore, let's convert
the assertions into errors.
Fixes: 8fa1b5a00b ("zdump: dfi: add support to read Protected Virtualization dumps")
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Steffen Eiden <seiden@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Make zipl tool prepare ECKD DASD for booting by different IPL
programs (with the same boot record installed).
Besides standard CCW-type IPL, user gets an ability to trigger
(with the same boot record installed!) List-Directed IPL. This
allows to use the feature of secure boot from ECKD DASD (which
is not available for CCW-type IPL).
When using the old boot interfaces, the usual CCW-type IPL is
triggered for DASD. Also for compatibility reasons zipl(8) tool
is modified to create and install one, or two "similar" program
tables per boot partition, depending on job and disk type. The
"similar" program tables differ only in block pointers format.
The old IPL programs (CCW-type IPL) use program table based on the
old format.
All program tables are packed to the same bootmap file. Their
order and logical offsets in the file are not significant (not
used by anyone).
The picture below shows which program table is used for IPL of
specified type from disk of specified type. Here "0" and "1" are
identifiers of program tables based on the old and new block
pointers format respectively. E.g. program table "0" is used for
CCW-type IPL from ECKD DASD. LD-IPL from DASD FBA is unsupported
(respectively, only one program table "0" is used), etc.
CCW-IPL LD-IPL
SCSI X 0
DASD FBA 0 X
ECKD DASD LDL 0 X
ECKD DASD CDL 0 1
Signed-off-by: Eduard Shishkin <edward6@linux.ibm.com>
Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add an option to tunedasd to trigger a copy pair swap using the appropriate
ioctl for DASD devices.
-s, --copy-pair-swap COPY_PAIR
This command requires a comma separated pair of primary,secondary to be
specified. In case of success the old secondary will become the new primary
device and the old primary will become a secondary device.
Example:
tunedasd /dev/dasda -s 0.0.9700,0.0.9740
This will set the old secondary device 0.0.9740 as the new primary.
The old primary device 0.0.9700 will automatically become a secondary
device.
Signed-off-by: Stefan Haberland <sth@linux.ibm.com>
Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
In case of an error the ioctl macro only returns errno to the calling
function.
This misses positive returncodes from ioctls.
Change the macro to also return positive return codes.
Signed-off-by: Stefan Haberland <sth@linux.ibm.com>
Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The DASD device driver has a new attribute copy_pair to make storage
server copy pairs known to the driver.
Add this attribute to zdev.
Usage example:
Add two copy pairs 1000,2000 and 1000,3000 to a DASD device 1000
$ chzdev dasd 1000 copy_pairs=1000,2000 copy_pairs=1000,3000
or
$ chzdev dasd 1000 copy_pairs="1000,2000 1000,3000"
To add a third copy pair later on:
$ chzdev dasd 1000 copy_pairs=1000,4000
To remove all copy pairs from the device 1000:
$ chzdev dasd 1000 -r copy_pairs
Signed-off-by: Stefan Haberland <sth@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add an option -P|--copy-pairs to show all DASD devices with copy
relations set up in the system and their roles.
The output looks like:
# ./s390-tools/zconf/lsdasd -h
[...]
-P|--copy-pairs
Print information about copy pairs.
# ./s390-tools/zconf/lsdasd -P
Bus-ID Role Name Paired devices
================================================================================
0.0.9700 primary dasdd 0.0.9740,0.0.9743,0.0.9744,0.0.9745
0.0.9740 secondary 0.0.9700
0.0.9701 primary dasdf 0.0.9741
0.0.9741 secondary 0.0.9701
0.0.9702 primary dasdh 0.0.9742
0.0.9742 secondary 0.0.9702
Signed-off-by: Stefan Haberland <sth@linux.ibm.com>
Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Adds util_lockfile_example.c, which can be used to sample
util_lockfile support.
To acquire a lock using a parent PID (e.g. your shell instance):
util_lockfile_exmample -f <path> -l <retries>
To release the lock using the parent PID:
util_lockfile_example -f <path> -r
To acquire the lock, sleep briefly, and then release the lock
using the PID of the util_lockfile_example process:
util_lockfile_example -f <path> -L <retries>
In each example, the <path> is the location of the desired lockfile
and <retries> is the number of times to retry acquiring the lock
if it fails.
GitHub-ID: https://github.com/ibm-s390-linux/s390-tools/issues/142
Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com>
Reviewed-by: Steffen Eiden <seiden@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Implement simple file-locking routines that use process PIDs for stale
lock detection. The implementation is meant to be a simplified subset of
what liblockfile was previously being used for by libap, allowing the
external dependency to be removed.
This initial implementation provides a series of functions that allow for
creating/release file locks using either the current process PID or the
PID of the current process parent. When creating a file lock, first a
temporary file is created and the appropriate PID (either this process
PID or the parent process PID) is placed in the file to specify the owner
of the lock. Then an attempt is made to link that file to the desired
file location; if this succeeds, the lock is now held on behalf of the
specified PID. If it fails, this implies the file already exists
(meaning the lock is already held). In this case, stale lock detection
is performed by reading the PID from the file and ensuring that the
associated process still exists -- if it does not, then the lock is
presumed stale and destroyed. If the process still exists, then either
the lock request fails or the caller will sleep and retry, depending on
an optional retry setting.
A lock remains valid until either 1) it is released via the corresponding
util_lockfile function, which will delete the corresponding file 2) the
associated PID no longer exists, which leaves the file in-place but will
cause it to be destroyed the next time a different process attempts to
lock that file or 3) the file is directly removed (e.g. rm).
A typical usecase for such support would be to provide a means for
multiple invocations of the same (or different) tools to ensure that they
do not access the same shared resource simultaneously. For example,
ap-check, chzdev and lszdev all have a need to view and/or modify the AP
and vfio-ap configuration files; util_lockfile can be used to ensure that
only one instance of any of these utilities do that at a time by ensuring
they all use the same lockfile.
Additionally, providing the ability to specify the parent PID rather than
the current PID allows for a general purpose tool (like mdevctl) to
invoke a sub-program (ap-check) to acquire and release a lockfile as
necssary while allowing stale lock detection to be controlled by that
parent PID, allowing the lock to remain held over multiple sub-program
invocations.
Note that this implementation is sufficient for our current usage (e.g.
lockfiles placed in tmpfs) but does not take into consideration things
like NFS, which a more complete lockfile solution like liblockfile does.
GitHub-ID: https://github.com/ibm-s390-linux/s390-tools/issues/142
Suggested-by: Luca BRUNO <luca.bruno@coreos.com>
Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com>
Reviewed-by: Steffen Eiden <seiden@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Set up the secure_boot_supported global variable at the
function bootmap_create() instead of bootmap_create_device()
to make sure that the secure boot status is checked for all
relevant jobs.
Fixes: 7b369318dd ("zipl: check for secure boot once")
Signed-off-by: Eduard Shishkin <edward6@linux.ibm.com>
Reviewed-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
