The tape390_display tool was used to send text to the display of tape
storage server. The corresponding command is still accepted by the
Virtual Tape Server (VTS) but no action is performed. The tool is
useless, remove it.
The tape390_crypt tool was used to manage encryption for tape devices.
However, only 3590/3592 models did support encryption. Support for these
models is removed from the Kernel as there is no support for these tape
models in general anymore. The tool is not required anymore, remove it.
Note: VTS uses encryption transparantly for its virtualized 3490 models.
Reviewed-by: Jens Remus <jremus@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Rename .exec into .elf because they are ELF files, no reason to use a
different file extension.
This change improves the shell's autocompletion of tools such as
'readelf'.
Acked-by: Mikhail Zaslonko <zaslonko@linux.ibm.com>
Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Function ekmf_validate_cert() checks if the public key contained in a x509
certificate matches the public key of the identity key.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Finn Callies <fcallies@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
s390 is able to provide memory topology information of the current CEC
via a new userspace-kernel interface. zmemtopo is a tool to convert the
raw data into human readable form.
Usage: zmemtopo [OPTIONS]
Display CEC memory topology of allocated memory increments.
OUTPUT FORMAT OPTIONS
-l, --level NESTING_LEVEL Set the topology display depth to NESTING_LEVEL
-f, --full Display tree view with padded elements
-r, --reverse Reverse tree view hierarchy direction
-t, --table Use table view to display topology
-s, --sort FIELD Sort view by field
(nr, lpar, size)
-i, --ascii Use only ASCII characters
GENERAL OPTIONS
-h, --help Print this help, then exit
-v, --version Print version information, then exit
Upon calling zmemtopo displays available topology level's structure
and memory increments defined on each topology location.
Ex:
$ zmemtopo
LPAR/LEVEL SIZE
LPAR003 8G
└LEVEL4_0 8G
├LEVEL3_0 2G
├LEVEL3_1 2G
├LEVEL3_2 2G
└LEVEL3_3 2G
LPAR005 8G
└LEVEL4_1 8G
├LEVEL3_0 2G
├LEVEL3_1 2G
├LEVEL3_2 2G
└LEVEL3_3 2G
LPAR006 8G
└LEVEL4_3 8G
...
Signed-off-by: Mete Durlu <meted@linux.ibm.com>
Reviewed-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
zpwr displays power readings of a partition and central processing
complex (CPC) from power information block (pib). pib is retrieved by
issuing diag324 ioctl to /dev/diag device.
Reviewed-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add a new tool named chpstat that can be used to view channel-path
statistics such as utilization and I/O throughput, and to query and
control the status of the channel-path statistics function.
Note: Channel-path statistics are only available on systems running in
an LPAR or DPM partition.
When run without further options, data for all channel-paths is
displayed repeatedly with a 5 second delay in table format.
Example output:
CHANNEL-PATH UTILIZATION(%) READ(B/s) WRITE(B/s)
ID TYP CMG SHR SPEED PART TOTAL BUS PART TOTAL PART TOTAL
1d 25 2 1 - 7.16 7.50 7.50 129M 129M 0.00 161K
21 1b 2 1 32G 0.00 0.00 0.00 0.00 0.00 0.00 0.00
34 1b 2 1 32G 0.00 0.00 0.00 0.00 0.00 0.00 0.00
61 25 2 1 - 0.00 0.01 0.00 0.00 2.00K 0.00 307K
63 25 2 1 - 0.00 0.01 0.00 0.00 0.00 0.00 381K
bd 11 2 1 10G - - - 529.8 532.1 616.3 616.3
Reviewed-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Currently, the debug information of the bootloader is discarded during
the raw binary creation. Change this by creating separate
<loader>.bin.debug files containing the debug information. The packager
will then be able to package these files as desired and the developer
can use them to debug the code.
Reviewed-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Currently, each generated loader binary is linked into one data.o object
file which is then linked against boot.o. The data.o file is also used
to generate the data.h header file using nm, which will contain all
symbols required by zipl.
The linking process is somewhat depended on the directory, as the symbol
names are derived from the file names of the input files, which is the
default behavior of the linker. The file name in this case being the
entire path.
Examples for the current situation (starting from root dir in each case):
$ cd zipl/boot && make eckd0_cdl.bin
$ cc -no-pie -static -nostdlib -Wl,--relocatable -Wl,--format,binary -o data.o eckd0_cdl.bin
$ nm data.o
0000000000000018 D _binary_eckd0_cdl_bin_end
0000000000000018 A _binary_eckd0_cdl_bin_size
0000000000000000 D _binary_eckd0_cdl_bin_start
$ make -C zipl/boot eckd0_cdl.bin
$ cc -no-pie -static -nostdlib -Wl,--relocatable -Wl,--format,binary -o data.o zipl/boot/eckd0_cdl.bin
$ nm data.o
000000000000018 D _binary_zipl_boot_eckd0_cdl_bin_end
000000000000018 A _binary_zipl_boot_eckd0_cdl_bin_size
000000000000000 D _binary_zipl_boot_eckd0_cdl_bin_start
The example above shows that the entire path would end up in the symbol
name if specified that way.
To make this more robust, future proof, and get more control of the
resulting symbol names, use '.incbin' and some macros for embedding the
loader binary files. This also reduces the linker step and the
generation of the data.h header file.
Reviewed-by: Steffen Eiden <seiden@linux.ibm.com>
Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Co-developed-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@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>
pvattest is a tool to attest an IBM Secure Execution guest.
In a trusted environment, one can create a request using
`pvattest create`. To get a measurement of an untrusted
IBM Secure Execution guest call 'pvattest perform'.
Again in a trusted environment, call 'pvattest verify'
to verify that the measurement is the expected one.
The tool runs on s390 and x86.
It has the same requirements like libpv and therefore
requires openssl v1.1.1+, glib2.56+, and libcurl.
Additionally, to measure, the linux kernel must provide
the Ultravisor userspace interface `uvdevice` at /dev/uv
and must be executed on an IBM Secure Execution guest on
hardware with Ultravisor attestation support, like IBM z16 or later.
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Reviewed-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The ap_tools utilities are intended to be used in conjunction with
the mdevctl utility for safely managing and inspecting vfio-ap
mediated devices. For now, this will consist of the ap-check tool
which will be driven via a call-out from mdevctl to validate a
proposed vfio-ap mediated device change.
Reviewed-by: Jan Höppner <hoeppner@linux.ibm.com>
Reviewed-by: Tony Krowiak <akrowiak@linux.ibm.com>
Reviewed-by: Jason J. Herne <jjherne@linux.ibm.com>
Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The Processor Activity Instrumentation facility (PAI) uses the
perf_event_open system call to report data and the crypto counter
values. The data can be inspected with the perf tool in a very
generic way using raw data report and a hex dump utility.
The pai tool also uses the perf_event_open system call to record the
data, but uses specialized event attributes for recording detailed
information such as the recording of fork, exit, exec system call
events and context switch events.
Cryptography counter values are appended as raw data attachments.
The pai command can be used for recording and reporting.
Also a list of CPUs can be specified.
The recording ring buffers are created per CPU
and are named paicrypto.XXX where XXX stands for the CPU number.
The numbering scheme has leading zeros, such as 007 for CPU number 7.
For invocation and possible command line options see the man page.
Signed-off-by: Thomas Richter <tmricht@linux.ibm.com>
Reviewed-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add support to integrate the external key management systems based
on the KMIP protocol (KMIP: OASIS Key Management Interoperability
Protocol) into zkey by providing a zkey KMS plugin for KMIP. The
plugin communicates with KMIP servers using libkmipclient over a
TLS or HTTPS connection.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
libkmipclient is a shared library that provides an KMIP client to
communicate with an KMIP server. KMIP stands for Key Management
Interoperability Protocol, and is an extensible communication protocol
that defines message formats for the manipulation of cryptographic
keys on a key management server.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The libseckey is a secure key library to perform secure key operations
with OpenSSL. It provides a framework to create OpenSSL PKEYs with a
secure key attached. Such a PKEY contains the public key parts in clear,
but the private key as secure key blob. Only the private key operations
are actually performed with the secure key, public key operations are
performed in software by OpenSSL. It supports CCA and EP11 secure
keys for RSA and ECC crypto operations.
Because many PKEY method related functions are deprecated since OpenSSL
3.0, two versions of the OpenSSL secure key support are needed. One (using
a PKEY method override) for OpenSSL 1.1.1, and another one (using an own
OpenSSL provider) for OpenSSL 3.0 and later. The desired implementation is
selected automatically at compile time, using OpenSSL version defines. The
interface of both implementations is the same, so a user does not need to
care which one is used.
Reviewed-by: Juergen Christ <jchrist@linux.ibm.com>
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
