This adds support for long command lines. The boot loader stages
will no longer use a fixed limit when copying the command line, but
will use the maximum length from the kernel image that is being loaded.
Signed-off-by: Sven Schnelle <svens@linux.ibm.com>
Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add generic functions
util_sysdir();
util_sysdir_path()
and their special cases supplied for users:
util_libdir();
util_libdir_path();
util_datadir();
util_datadir_path()
The function util_sysdir() determines the absolute name of a
s390-tools system directory. It could be data, or library directory.
The function util_sysdir_path() determines the absolute name of a
file installed in the s390-tools system directory.
The function util_libdir() determines the absolute name of a
s390-tools library directory. By default that name is defined
by the compile-time macro TOOLS_LIBDIR (/lib/s390-tools).
Users can specify an override by setting environment variable
S390TOOLS_LIBDIR.
The function util_libdir_path() determines the absolute name of a
file installed in the s390-tools library directory.
The function util_datadir() determines the absolute name of a
s390-tools system data directory. By default the name is defined
by the compile-time macro TOOLS_DATADIR (/usr/share/s390-tools/).
Users can specify an override by setting environment variable
S390TOOLS_DATADIR.
The function util_datadir_path() determines the absolute name of a
file installed in the s390-tools data directory.
The ability to override the setting for TOOLS_LIBDIR and
TOOLS_DATADIR is required for implementing tests on tools that are
not installed in their default system path locations.
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>
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>
The util_arch module is supposed to provide general information about
the underlying architecture of the machine in use.
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Reviewed-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The only user of util_proc_mnt_get_entry() so far was util_path_sysfs().
With the simplified version there is no user left. Remove
util_proc_mnt_get_entry() and related code.
Reviewed-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The goal of util_log is to provide a facility for a multi-level message
logging on stderr. This allows to selectively enable/disable log messages
via a log level which can be adjusted at runtime.
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com>
Reviewed-by: Philipp Rudo <prudo@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add codepage conversion capabilities to libzds.
Whenever a dataset is read and an appropriate iconv handle is set for the
dataset the conversion is automatically performed.
Signed-off-by: Stefan Haberland <sth@linux.ibm.com>
Reviewed-by: Niklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Some operations are only possible on base devices not on partitions.
Add functions to determine if a given device is a partition or a base
device and to get the base device to a given partition.
Signed-off-by: Stefan Haberland <sth@linux.ibm.com>
Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com>
Reviewed-by: Philipp Rudo <prudo@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Retrieve EKMF Web settings such as the template names used by
EKMF Web for generating identity keys, as well as volume encryption
keys (XTS and non-XTS). Also check that the EKMF Web server has the
required 'Pervasive Encryption' feature installed.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
To perform operations in EKMF Web, the user must log in with a EKMF Web
user id and a time based one time passcode. The passcode can be obtained
by the user from the EKMF Web user interface, after logging in into EKMF
Web. That way a two factor authentication is performed. The client passes
the passcode to EKMF Web retrieves a bearer token from EKMF Web which it
then uses on subsequent requests to authenticate with EKMF Web. Such a
bearer token is valid for several minutes, thus no re-login is required
for zkey commands run during that time.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Allow to add, change and delete custom tags of a key. Custom tags
can be used store any kind of textual information with a key. Tags
have a name and a value.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
EKMF Web maintains a key state for each key. Keys can be in state
PRE-ACTIVATION, ACTIVE, DEACTIVATED, COMPROMISED, DESTROYED, and
DESTROYED-COMPROMISED. Key states can be changed as defined in NIST
Special Publication 800-57 Part 1.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Allow to request EKMF Web to generate a new key in its repository.
The newly generated key is generated based on the key template used.
Also, custom properties can be specified that are stored together with
the key, as well as export control information defining who is allowed
to request an export of the key later on.
Besides generating new random keys in EKMF Web, you can also register
the client's public identity key with EKMF Web by generating a new
identity key using an X.509 certificate containing the client's public
key.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Retrieve information about keys managed by EKMF Web, such as the
key algorithm, the key size and type. Additional, the key's tags
are retrieved. Label tags are used to build the label name of a key.
Custom tags can be used to store any kind of textual data together with
a key.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Key templates are used by EKMF Web to generate new keys. The template
specifies the key algorithm, the key size, and type (e.g. CCA DATA or
CIPHER). It also determines how a newly generated key is named through
a key label template containing label tags.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
To retrieve a secure key from EKMF Web, a Elliptic-curve Diffie-Hellman
(EC-DH) protocol is used to securely transport the key, without revealing
the key to be transported in clear. The key to be transported remains
encrypted all the time, either encrypted with the master key of the
cryptographic adapter on the source or target side, or with a transport
key, that is derived using the EC-DH key agreement protocol. The transport
key is also a secure key, itself encrypted with the master key of the
cryptographic adapters on both sides.
To generate the transport key, each side generates a new secure ECC
session key with its cryptographic adapter. This session keys are then
used with EC-DH to derive the secure transport key. The secure key to
be transported is then exported by EKMF Web under the transport key, is
sent to the client, and is then imported using the transport key.
The key retrieval request is signed using the identity key of the client.
EKMF Web knows the public key of the client's identity key through a one
time registration process, and can therefore verify the signature with
the client's public key. The response is also signed by the EKMF Web
server's identity key, and the client can verify the signature with the
server's public key that it retrieved once during registration.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
To identify the client with EKMF Web, an X.509 certificate must be
generated using the identity key, and must be made known to EKMF Web.
Either a self signed certificate can be generated, or a certificate
signing request (CSR) that is then passed to a certificate authority
(CA) to have a certificate issued. The certificate is then used to
register the client with EKMF Web, so that EKMF Web knows the public
part of the client's identity key.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The identity key of the client is a secure key enciphered with the
master key of a cryptographic adapter (APQN). When the master key of
the used APQNs is changed, the identity key must be re-enciphered
under the new master key.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
To identify the client with EKMF Web, the client generates a secure
ECC or RSA identity key. This identity key is then used to
cryptographically sign certain requests sent to EKMF Web.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
When login in with EKMF Web, a bearer token is retrieved from EKMF Web
which is then used on subsequent requests to authenticate with EKMF Web.
Such a bearer token is valid for several minutes, thus no re-login is
required during that time. The bearer token contains a JSON Web Token
(JWT, see RFC7519).
Allow to check such a token if it is still valid, or already expired.
That way a client application can check the token before issuing the next
request, and re-login if needed.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The EKMFWeb client library provides functions to communicate
with an EKMF Web server via REST calls over HTTPS. EKMF Web stands
for IBM Enterprise Key Management Foundation - Web Edition and is
used to manage keys in an enterprise.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
For data consistency it is essential that datasets are not modified by
z/OS applications during zdsfs access. This is currently ensured by
manually setting the device offline in z/OS before mounting it in Linux.
This patch improves the usability and data security by making this manual
step obsolete.
Before opening a dataset zdsfs will obtain an ENQ to mark it as in use for
z/OS and release the ENQ when closing the dataset.
A timer is set up that pings the z/OSMF REST services with the ENQ to
prevent it from a timeout after 10 minutes.
The behavior of zdsfs can be configured in a new config file or with new
command line options.
Signed-off-by: Stefan Haberland <sth@linux.ibm.com>
Reviewed-by: Niklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add library functions that allow to communicate with z/OSMF REST services
using libcurl.
Following three functions are added:
lzds_rest_get_enq()
to obtain an ENQ that will mark a dataset as in use to z/OS until
it is released again
lzds_rest_release_enq()
to release an ENQ and mark a dataset as no longer in use to z/OS
lzds_rest_ping()
to ping a z/OSMF REST server to check if it accessible
or to refresh an ENQ and prevent it from a timeout after 10 minutes
Signed-off-by: Stefan Haberland <sth@linux.ibm.com>
Reviewed-by: Niklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
This fixes an error when genprotimg is compiled with clang and the
sanitizers address and undefined behaviour enabled.
pv/pv_ipib.c:47:33: runtime error: member access within misaligned address 0x62100000a100 for type 'IplParameterBlock' (aka 'struct ipl_parameter_block'), which requires 4096 byte alignment
0x62100000a100: note: pointer points here
01 00 00 45 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
^
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior pv/pv_ipib.c:47:33 in
This change should be no problem as genprotimg is the only user.
Reviewed-by: Philipp Rudo <prudo@linux.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
While at it, rename PSW_SHORT_ADDR_MASK and PSW_ADDRESS_MASK to
PSW32_ADDR_MASK. As a side effect this removes the zipl.h dependency
of the boot loaders. While at it,
Reviewed-by: Philipp Rudo <prudo@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>
Use C pre-processor for linker script generation and refactor some
constants. This allows the usage of the constants in our "linker
scripts" `*.lds.S` (actually, these are assembler files, so we can
make us of the C pre-processor and its capabilities).
While at it, enforce the described memory layout in the generated
linker script.
Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
Reviewed-by: Philipp Rudo <prudo@linux.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Move COMMAND_LINE_EXTRA to `boot/loaders_layout.h` so it can be reused
by `menu.c`and `stage3.c`. Additionally, reuse COMMAND_LINE_SIZE from
`linux_layout.h` in `menu.c`.
Reviewed-by: Philipp Rudo <prudo@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>
The lowcore parmblock pointer is not valid in every case. For example
it is invalid for CCW type IPL.
To have an indication if the pointer is valid do a diag308 to store the
parmblock and check if secure boot is enabled.
If it is enabled the lowcore pointer is valid and the ipl report that is
needed for secure boot can be found right behind the ipl parmblock.
Signed-off-by: Stefan Haberland <sth@linux.ibm.com>
Reviewed-by: Philipp Rudo <prudo@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Protected VMs (PVM) are KVM VMs, where KVM can't access the VM's state
like guest memory and guest registers anymore. Instead the PVMs are
mostly managed by a new entity called Ultravisor (UV), which provides
an API, so KVM and the PV can request management actions.
PVMs are encrypted at rest and protected from hypervisor access while
running. They switch from a normal operation into protected mode, so
we can still use the standard boot process to load an encrypted image
and then move it into protected mode.
This commit adds the tool 'genprotimg'. It takes a kernel, key files,
optionally an initrd, optionally a file with the kernel command line,
and it generates a single, loadable image file. The image consists of
a concatenation of a plain text boot loader, the encrypted components
for kernel, initrd, and cmdline, and the integrity-protected PV
header, containing metadata necessary for running the guest in PV
mode.
It's possible to use this image file as a kernel for zipl or for a
direct kernel boot using QEMU.
Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com>
Acked-by: Patrick Steuer <patrick.steuer@de.ibm.com>
Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
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>
`linux/asm/types.h` also defines the struct `__vector128` so in order
to avoid definition conflicts add the macro guard _S390_TYPES_H, which
is defined in `linux/asm/types`. `linux/asm/types.h` is included by
glib2, which is used by the PV tooling.
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>
Add a boot loader for protected virtualization (PV) that can be
combined with a kernel/initrd/parmfile to form a single bootable file.
This file must be constructed in a way that it can be used (1) for a
QEMU direct kernel boot and (2) it can be zipl'ed by the normal,
unmodified zipl program.
This new boot loader consists of two parts:
1. stage3a boot loader (cleartext), this loader is responsible for
the transition into the protected mode by doing diag308 subcode 8
and 10 calls.
2. stage3b boot loader (encrypted), this loader is very similar to the
normal zipl stage3 boot loader. It will be loaded by the Ultravisor
after the successful transition into protected mode. Like the zipl
stage3 boot loader it moves the kernel and patches in the values
for initrd and parmline.
The requirements for (1) and (2) result in the following constraints:
1. It must be possible to place stage3a and stage3b at a location >=
0x10000 because the zipl stage3 loader zeroes out everything at
addresses lower than 0x10000 of the image.
2. As the stage3 loader of zipl assumes that the passed kernel image
looks like a normal kernel image, the zipl stage3 loader modifies the
content at the memory area 0x10400 - 0x10800, therefore we leave this
area unused in our stage3a loader.
3. The default entry address used by the zipl stage3 loader is 0x10000
so we add a simple branch to 0x11000 at 0x10000 so the zipl stage3
loader can modify the area 0x10400 - 0x10800 without affecting the
stage3a loader.
The stage3b loader is linked at address 0x9000, therefore it will not
work at another address. The relocation support for the stage3b
loader, so that it can be placed at addresses != 0x9000, is added in
the next patch. This loader with relocation support has the name
'stage3b_reloc'.
The memory layout of the single bootable file looks like:
+-----------------------+-----------+------------------------+
|Start |End |Use |
+=======================+===========+========================+
|0 |0x7 |Short PSW, starting |
| | |instruction at 0x11000 |
+-----------------------+-----------+------------------------+
|0x10000 |0x10012 |Branch to 0x11000 |
+-----------------------+-----------+------------------------+
|0x10013 |0x10fff |Left intentionally |
| | |unused |
+-----------------------+-----------+------------------------+
|0x11000 |0x12fff |Stage3a |
+-----------------------+-----------+------------------------+
|0x13000 |0x13fff |IPIB used as argument |
| | |for the diag308 call |
+-----------------------+-----------+------------------------+
|0x14000 |0x1[45]fff |UV header used for the |
| | |diag308 call (size can |
| | |be either 1 or 2 pages) |
+-----------------------+-----------+------------------------+
|NEXT_PAGE_ALIGNED_ADDR | |Encrypted Kernel |
+-----------------------+-----------+------------------------+
|NEXT_PAGE_ALIGNED_ADDR | |Encrypted Cmdline |
+-----------------------+-----------+------------------------+
|NEXT_PAGE_ALIGNED_ADDR | |Encrypted Initrd |
+-----------------------+-----------+------------------------+
|NEXT_PAGE_ALIGNED_ADDR | |Encrypted Stage3b_reloc |
+-----------------------+-----------+------------------------+
Reviewed-by: Philipp Rudo <prudo@linux.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Consolidate `ALIGN, __ALIGN_MASK, ARRAY_SIZE` macros and add them to
lib/zt_common.h. While at it, adapt coding style.
Reviewed-by: Philipp Rudo <prudo@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>
Errors fixed:
../../include/boot/s390.h: In function '__stfle_asm':
../../include/boot/s390.h:424:41: error: conversion to 'long unsigned int' from 'int' may change the sign of the result [-Werror=sign-conversion]
register unsigned long reg0 asm("0") = size - 1;
../../include/boot/s390.h: In function 'stfle':
../../include/boot/s390.h:453:31: error: conversion to 'long unsigned int' from 'int' may change the sign of the result [-Werror=sign-conversion]
nr = MIN((nr + 1) * 8, size * 8UL);
../../include/boot/s390.h: In function 'diag308':
../../include/boot/s390.h:296:9: error: conversion from 'long unsigned int' to 'int' may change value [-Werror=conversion]
return _rc;
Reviewed-by: Philipp Rudo <prudo@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>
Now that we made sure that s390.h can be used with our minimal libc
implementation and glibc move s390.h to `include/boot/s390.h`. While
at it, make sure that s390.h is assembler compatible as it will be
used later in the PV boot loader and include s390.h in ipl.h as
PAGE_SIZE is used there.
Reviewed-by: Philipp Rudo <prudo@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>
Move the loaders (stage2/stage3) layout values to
`include/boot/loaders_layout.h` and use the `_AC` macro for the
constants. This allows the reuse of the definitions, e.g. in assembler
files, and later for the creation of linker scripts.
Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
Reviewed-by: Philipp Rudo <prudo@linux.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Use the constants defined in `linux_layout.h`. Therefore move the
`PARMAREA` address offset to `linux_layout.h` and include the header.
Reviewed-by: Philipp Rudo <prudo@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>
Move the Linux layout values to `include/boot/linux_layout.h`. This
allows the reuse of the definitions, e.g. in assembler files, and
later for the creation of linker scripts.
Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
Reviewed-by: Philipp Rudo <prudo@linux.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
