List (find) and import a key that exists in a KMIP server into the zkey
repository. Retrieve the key attributes of a key stored in a KMIP server,
and extract the zkey properties from it.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
When a key is removed from the zkey repository, it is usually not removed
from the KMIP server. Optionally, the state of a KMIP key can be changed
when it is removed by zkey.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Change the attributes of a key at the KMIP server when the properties
of a key are changed in zkey.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Allow to generate a new AES key at the KMIP server, and retrieved it.
Keys are always retrieved in wrapped format, wrapped by the public RSA
wrapping key used by the KMIP plugin. The KMIP plugin can then unwrap
the retrieved key with its secure private RSA key, and can then import
the retrieved AES key into the zkey repository as secure key. That way,
the retrieved AES key is never in clear, once it leaves the KMIP server.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
When the master keys of the configured APQNs are changed, the secure
identity key as well as the secure wrapping key must be re-enciphered.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Keys retrieved from a KMIP server are wrapped with an RSA key. The
RSA wrapping key is a secure key generated by the KMIP plugin. The
public RSA key is registered at the KMIP server, and the KMIP server
can then wrap the keys with it. The KMIP plugin can unwrap the retrieved
key with the private RSA key and import it as secure key into the zkey
repository.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Configure a connection to a KMIP server, establish trust between
server and client, query the KMIP server and verify if it supports
the required KMIP operations. Also, the profile to be used with this
KMIP server is tried to matched. If not specified in the profile,
the KMIP protocol version to be used is discovered.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
KMIP server profiles (not to be confused with profiles defined by
the KMIP standard) define how the KMIP plugin talks to the KMIP
server. Profiles can be used to configure certain KMIP usages for
certain KMIP servers.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Lines with '#' as first character are treated as comments, and are
skipped. Empty lines are also skipped.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
For the client certificate to authenticate with the KMIP server,
a certificate signing request (CSR) or self signed certificate can be
generated. The generated CSR or certificate is signed with the secure
identity key of the KMIP plugin.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Authentication with KMIP servers is based on TLS client authentication.
To establish trust between zkey and the KMIP server, a client certificate
must be registered with the KMIP server before a client can communicate
with it.
The signature key of the client's certificate is a secure key created by
zkey. It can either be an RSA or an ECC key, using either CCA or EP11
type crypto adapters configured with the KMIP plugin.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The KMIP plugin supports CCA and EP11 APQNs, but only it can only be
configured with one type. Once configured with one type of APQN, it accepts
only APQNs of the same type.
It supports key types matching to the APQn type it is configured with.
Signed-off-by: Ingo Franzki <ifranzki@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>
Some functions are likely to be used by multiple plugins. Move them
into zkey common code (plugin-utils.c), this module is then linked
into the plugins.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
KMS plugins that support multiple key types need to know which
key type to produce with the kms_import_key() function. Extend
the plugin API to allow a plugin to provide a kms_import_key2()
function, that accepts the key type as additional parameter.
Existing plugins do not need to be changed, as the old function
kms_import_key() still exists, and is still used when the plugin
does not provide a kms_import_key2() function.
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>
The new user-defined function allows to check for C headers in
make's conditional statements.
Example:
ifeq ($(call check_header_prereq,"systemd/sd-daemon.h"),yes)
$(warning "systemd support enabled")
else
$(warning "systemd support disabled")
endif
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Acked-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The callback function used for CURLOPT_SSL_CTX_FUNCTION requires
that OpenSSL is used as SSL backend.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add the genprotimg flags `--(enable|disable)-pckmo` flag to enable/disable the
support for PCKMO-encrypt-DEA/TDEA/AES/ECC-key functions.
Acked-by: Viktor Mihajlovski <mihajlov@linux.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Allow the PCKMO-encrypt-DEA/TDEA/AES/ECC-key functions to be used in a protected
virtualization guest by default.
Acked-by: Viktor Mihajlovski <mihajlov@linux.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The new name reflects that it's a plaintext control flag. While at it, use a
left shift operation to calculate the value.
Acked-by: Viktor Mihajlovski <mihajlov@linux.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The HSA size, which limits the address space in kdump case, is not constant
and depends on the underlying architecture.
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 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>
... to avoid vulnerabilities that could occur if set-user-ID or
set-group-ID programs accidentally trusted the environment.
zkey is usually NOT a set-user-ID or set-group-ID program, but its
safer to use secure_getenv() anyway.
Signed-off-by: Ingo Franzki <ifranzki@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>
Using util_path_sysfs always leaves 5 bytes of memory unfreed as the
value for the sysfs mount point is stored in a static variable to avoid
multiple queries of /proc/mount.
$ valgrind ./util_path_example sysfs
==3629315== Memcheck, a memory error detector
==3629315== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==3629315== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==3629315== Command: ./util_path_example sysfs
==3629315==
Path for cpu: "/sys/devices/system/cpu"
Path for memory: "/sys/devices/system/memory"
==3629315==
==3629315== HEAP SUMMARY:
==3629315== in use at exit: 5 bytes in 1 blocks
==3629315== total heap usage: 22 allocs, 21 frees, 18,435 bytes allocated
==3629315==
==3629315== LEAK SUMMARY:
==3629315== definitely lost: 0 bytes in 0 blocks
==3629315== indirectly lost: 0 bytes in 0 blocks
==3629315== possibly lost: 0 bytes in 0 blocks
==3629315== still reachable: 5 bytes in 1 blocks
==3629315== suppressed: 0 bytes in 0 blocks
==3629315== Rerun with --leak-check=full to see details of leaked memory
==3629315==
==3629315== For lists of detected and suppressed errors, rerun with: -s
==3629315== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
As per the Kernel rules for accessing sysfs information [1], searching
for the sysfs mount point is a waste of time and systems that don't have
sysfs mounted at /sys are considered broken.
With those things in mind, util_path_sysfs() and especially
sys_mount_point() can be simplified. sys_mount_point() will always
return '/sys' unless the environment variable SYSFS_ROOT is set.
With SYSFS_ROOT still being present, special container setups or test
case scenarios are still possible but might need to be modified if they
previously relied on util_path_sysfs() automatically finding the correct
sysfs mount point.
To make things more secure against malicious strings in SYSFS_ROOT,
secure_getenv() is being used and the ordering of creating the formatted
path string in util_path_sysfs() is changed slightly.
Furthermore, the static variable is removed as no complicated query of
the /proc fs is required anymore. Memory for the sysfs mount point value
is properly freed now at the end of util_path_sysfs().
[1] https://www.kernel.org/doc/html/latest/admin-guide/sysfs-rules.html
Reviewed-by: Ingo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
A compile with sparse (make C=1) shows a couple of warnings:
like:
chzcrypt.c:36:3: warning: symbol 'l' was not declared.
Should it be static?
lszcrypt.c: In function 'show_device':
lszcrypt.c:556:9: warning: 'card' may be used uninitialized
[-Wmaybe-uninitialized]
Fix those warnings.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
A compile with sparse (make C=1) shows the following warnings:
util_rec.c:211:6: warning: symbol 'rec_print_wide' was not declared.
Should it be static?
util_rec.c:383:6: warning: symbol 'rec_print_csv_hdr' was not declared.
Should it be static?
util_rec.c:404:6: warning: symbol 'rec_print_csv' was not declared.
Should it be static?
These functions are only used internally from function util_rec_print_hdr(),
declare them as static.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
A compile with sparse (make C=1) shows the following warnings:
util_opt.c:42:19: warning: symbol 'util_opt_l' was not declared.
Should it be static?
util_prg.c:28:19: warning: symbol 'util_prg_l' was not declared.
Should it be static?
util_opt_l and util_prg_l are not used anywhere, and also not declared in
any header file. Looks like they are superfluous, remove them.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
hsavmcore is designed to make the dump process with kdump more efficient.
With hsavmcore, the HSA memory that contains a part of the production
kernel's memory can be released early in the process. Depending on the size
of the production kernel's memory, writing the dump to persistent storage
can be time consuming and prevent the HSA memory from being reused
by other LPARs.
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Reviewed-by: Philipp Rudo <prudo@linux.ibm.com>
Acked-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The CCA Key Translate2 verb needs a pre-built AES CIPHER key token skeleton
with XPRTCPAC set in the output buffer, to produce an AES CIPHER key
that can be exported to CAPCF.
Signed-off-by: Ingo Franzki <ifranzki@linux.ibm.com>
Reviewed-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
