Make use of the pre-defined __packed macro throughout zipl. This
requires adding the global include dir to ALL_CFLAGS.
Signed-off-by: Philipp Rudo <prudo@linux.ibm.com>
Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
When adding new header from zipl/include to a .c file within zipl/boot
a compiler error appears
stage3.c:16:10: fatal error: zipl.h: No such file or directory
#include "zipl.h"
^~~~~~~~
compilation terminated.
CC zipl/boot/stage3.o
This is because the rule to generate dependencies (*.o.d) does not use
the CFLAGS_BOOT. Thus it cannot find the header and fails. Note this
only applies to the dependency generation, the actual build succeeds.
To fix this rename the CFLAGS_BOOT to ALL_CFLAGS. Using ALL_CFLAGS
instead of e.g. ALL_CPPFLAGS is important to also overwrite flags given
on the commandline via OPT_FLAGS, e.g.
make V=1 OPT_FLAGS="-D__FOO__"
While at it also remove the unused and wrong '-D__ASSEMBLY__'.
Fixes: 5a6605fe ("zipl: Ensure that boot loader CFLAGS are not overwritten")
Fixes: aa913b1e ("build process: Add automatic dependency generation")
Signed-off-by: Philipp Rudo <prudo@linux.ibm.com>
Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Currently zipl doesn't differentiate between the load address and the
entry point of an image, causing stage3 to strip away the entry point at
0x10000 for stand-alone kdump. This breaks the kdump kernel as it jumps
to 0x10000 after the special handling needed for kdump has been
performed.
Fix this by differentiating between the load address and the entry point
of an image.
Fixes: d142fbd5 ("zipl: Do not strip kernel image IPL header")
Signed-off-by: Philipp Rudo <prudo@linux.ibm.com>
Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The __packed__ attribute is not needed for these structures as they
don't need any padding to meet the size and alignment constraints
defined in the Linux for zSeries ABI.
Reported by GCC 9.2.1 when building with '-Waddress-of-packed-member'.
stage3.c: In function 'is_verified_address':
stage3.c:241:26: warning: taking address of packed member of 'struct ipl_rb_components' may result in an unaligned pointer value [-Waddress-of-packed-member]
241 | for_each_rb_entry(comp, comps) {
| ^~~~~
stage3.c:18:15: note: in definition of macro 'for_each_rb_entry'
18 | for (entry = rb->entries; \
| ^~
CC zipl/boot/kdump3.o
CC zipl/boot/sclp_stage3.o
sclp_stage3.c: In function '__sclp_hsa_copy':
sclp_stage3.c:75:34: warning: converting a packed 'struct sdias_sccb' pointer (alignment 1) to a 'struct read_sccb' pointer (alignment 4096) may result in an unaligned pointer value [-Waddress-of-packed-member]
75 | if (sclp_hsa_copy_wait((struct read_sccb *)sccb))
| ^~~~~~~~~
In file included from sclp_stage3.c:13:
sclp_stage3.h:43:8: note: defined here
43 | struct sdias_sccb {
| ^~~~~~~~~~
In file included from sclp_stage3.c:12:
sclp.h:149:8: note: defined here
149 | struct read_sccb {
| ^~~~~~~~~
sclp_stage3.c: In function 'sclp_hsa_get_size':
sclp_stage3.c:126:34: warning: converting a packed 'struct sdias_sccb' pointer (alignment 1) to a 'struct read_sccb' pointer (alignment 4096) may result in an unaligned pointer value [-Waddress-of-packed-member]
126 | if (sclp_hsa_copy_wait((struct read_sccb *)sccb))
| ^~~~~~~~~
In file included from sclp_stage3.c:13:
sclp_stage3.h:43:8: note: defined here
43 | struct sdias_sccb {
| ^~~~~~~~~~
In file included from sclp_stage3.c:12:
sclp.h:149:8: note: defined here
149 | struct read_sccb {
| ^~~~~~~~~
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Reported by GCC 9.2.1 when building with '-Waddress-of-packed-member'.
menu.c: In function 'menu_read':
menu.c:30:22: warning: taking address of packed member of 'struct boot_stage2_params' may result in an unaligned pointer value [-Waddress-of-packed-member]
30 | uint16_t *configs = __stage2_params.config;
| ^~~~~~~~~~~~~~~
menu.c: In function 'menu_list':
menu.c:83:22: warning: taking address of packed member of 'struct boot_stage2_params' may result in an unaligned pointer value [-Waddress-of-packed-member]
83 | uint16_t *configs = __stage2_params.config;
| ^~~~~~~~~~~~~~~
menu.c: In function 'menu':
menu.c:139:22: warning: taking address of packed member of 'struct boot_stage2_params' may result in an unaligned pointer value [-Waddress-of-packed-member]
139 | uint16_t *configs = __stage2_params.config;
| ^~~~~~~~~~~~~~~
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Reported by GCC 9.2.1 when building with '-Wmaybe-uninitialized'.
job.c: In function 'job_get':
job.c:1817:14: warning: 'filename' may be used uninitialized in this function [-Wmaybe-uninitialized]
1817 | scan_size = scan_file(filename, &scan);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
job.c:1791:14: note: 'filename' was declared here
1791 | const char *filename;
| ^~~~~~~~
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Reported by GCC 9.2.1 when building with '-Wdiscarded-qualifiers'.
job.c: In function 'get_job_from_config_file':
job.c:1810:14: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
When calling ziomon --version (or --help) the tool already checks
whether blktrace is present and prevents any output for those command
options when it isn't. This is unnecessary as no actual command is
issued during the parameter check and all other dependencies are checked
at a later point as well.
Move the dependency check to ensure a working --version and --help
option at any time.
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
In the BLS files, the 'linux' and 'initrd' fields are relative to the
$BOOT directory. If $BOOT is a mount point of boot partition, 'linux'
and 'initrd' fields are relative to boot partition. If not, the paths
are relative to $BOOT directory of root partition.
zipl always starts searching at / regardless of partitions and mount
points.
This commit extends the semantics of target= field in zipl.conf to make
it as a second search path, besides /, for those 2 BLS fields.
See issues #69 for more details.
Fixes: https://github.com/ibm-s390-tools/s390-tools/issues/69
Closes: https://github.com/ibm-s390-tools/s390-tools/pull/74
Signed-off-by: Tuan Hoang <tmhoang@linux.ibm.com>
Signed-off-by: Stefan Haberland <sth@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The zipl config file (zipl.conf) and the BootLoaderSpec (BLS) fragments
in /boot/loader/entries define a set of tokens that are parsed by zipl.
These are stored in an array of tokens whose size is calculated to make
sure that there is enough memory allocated for all the scanned tokens.
But the size calculation logic was wrong, since it was checking if the
current size was enough to store a single token per BLS fragment, while
up to 4 tokens can be defined in a BLS file: a section heading and the
image, ramdisk and parameter keywords.
This led to zipl being killed by a SIGABRT signal when trying to parse
more tokens than the ones that could fit in the scanned tokens array:
Using config file '/etc/zipl.conf'
Using BLS config file '/boot/loader/entries/vmlinuz-9.conf'
Using BLS config file '/boot/loader/entries/vmlinuz-8.conf'
Using BLS config file '/boot/loader/entries/vmlinuz-7.conf'
Using BLS config file '/boot/loader/entries/vmlinuz-6.conf'
Using BLS config file '/boot/loader/entries/vmlinuz-5.conf'
Using BLS config file '/boot/loader/entries/vmlinuz-4.conf'
Using BLS config file '/boot/loader/entries/vmlinuz-3.conf'
Using BLS config file '/boot/loader/entries/vmlinuz-2.conf'
Using BLS config file '/boot/loader/entries/vmlinuz-1.conf'
Using BLS config file '/boot/loader/entries/vmlinuz-0.conf'
double free or corruption (out)
Aborted (core dumped)
Fixes: https://github.com/ibm-s390-tools/s390-tools/issues/68
Closes: https://github.com/ibm-s390-tools/s390-tools/pull/73
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Signed-off-by: Stefan Haberland <sth@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
This can be helpful in diagnosing network-related issues.
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The basic statistics are already collected via ifconfig. But that tool
is deprecated, and provides no way of collecting the extended stats.
So also gather data from 'ip link'.
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The duplicate statement does not have any effect. Therefore remove it.
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
When a secure key has been converted from type CCA-AESDATA to type
CCA-AESCIPHER, the secure key stored in the LUKS2 header of a volume
encrypted with that key should also changed.
Command 'zkey-cryptsetup setkey' allows to set (replace) the volume
key in the LUKS2 header. It now accepts keys to be set that have
a different size of the original volume keys. CCA-AESCIPHER keys
are larger than CCA-AESDATA keys.
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>
Add a new 'convert' command. It allows to convert a secure key from
one key type to another. Currently only keys of type CCA-AESDATA can be
converted to CCA-AESCIPHER.
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>
Perform extended checks on a secure key that is imported into
the key repository. Warn the user if the imported key is by
any means insecure, e.g. has been originally created in an
insecure way. Prompt the user to continue the import if a
potential insecurity is detected.
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>
The helper function performs a deep check of the AES CIPHER key
token and checks for any potentially insecure attributes.
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>
Secure keys of type CCA-AESCIPHER can be export restricted, so that
these keys can not be exported by another key.
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>
Some future functions are dependent on the firmware version of the
CCA crypto adapter. This helper function allows to query the version
of the currently selected CCA adapter.
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>
Secure keys of type CCA-AESCIPHER require a CEX6C or newer crypto
card. Also check for the minimum required card level during cross
checking of APQNs. Also display the card level in the APQN report.
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>
For secure keys of type CCA-AESCIPHER the CCA verb CSNBKTC2
(Key Token Change2) is used. CCA-AESDATA keys will continue
to use CCA verb CSNBKTC (Key Token Change).
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>
Add support for validating secure keys using the new pkey
IOCTLs. This allows to validate secure keys of type CCA-AESDATA
as well as CCA-AESCIPHER.
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>
Add support for generating secure keys using the new pkey
IOCTLs. This allows to generate secure keys of type CCA-AESDATA
as well as CCA-AESCIPHER, either by random inside the crypto
card, or from a given clear key.
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>
The new IOCTLs are based on list of APQNs that they try to send
the request to. Add some helper functions to build such lists
of APQNs based on the key type, and optionally a given mkvp.
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>
By default the new pkey IOCTL are used. In case the pkey device does not
support the new IOCTLs (i.e. errno ENOTTY is returned), then the wrapper
falls back to the old IOCTLs. The old IOCTLs only support secure keys of
type CCA-AESDATA.
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>
Add definitions and helper functions to support the new
CCA-AESCIPHER key type. Also enhance existing helper functions
to support CCA-AESCIPHER keys.
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>
Introduce helper functions and definitions to allow key type
independent code in the keystore implementation
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>
The zkey generate command allows to specify the --key-type|-K
option to specify the key type. If not specified, then the
default is CCA-AESDATA.
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>
The zkey list command now accepts option --key-type|-K type
to filter the displayed keys by key type. If not specified,
then all key types are displayed.
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>
For the 'zkey list', 'zkey validate' and 'zkey-cryptsetup validate'
commands, display the key type.
As of today there is only one possible key type (CCA-AESDATA),
but in the future there might be additional key types.
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>
This patch adds CEX7S exploitation support to lszcrypt and chzcrypt.
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
To allow better control about the secure AES volume key re-enciphering
with 'zkey-cryptsetup reencipher', add options '--to-new' and '--from-old'
to specify if a re-enciphering from CURRENT to NEW, or OLD to CURRENT master
key registers is to be performed. If these options are not specified, then
it is auto-detected, based on the master key that the secure key is currently
re-enciphered with.
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>
When re-enciphering secure AES keys, select the correct APQN for used
with the CCA host library. Re-enciphering a secure key requires the use
of the CCA host library. The APQN is selected based on the master key
verification pattern obtained from the secure key to re-encipher.
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>
Add a utility function to select an APQN that is set up with
a specific master key for use with the CCA host library. The
selection is based on the master key verification pattern, which
is typically obtained from an existing secure AES key.
The function iterates over a set of APQNs to find one that is setup
with the desired master key in the CURRENT or OLD master key register,
and optionally has a new master key loaded. It then selects the found
APQN for use with the CCA host library.
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>
Some operations require the CCA host library to be used, such as
re-enciphering a secure key. The CCA host library uses a different
approach to select the APQN it operates with. To ensure that the
desired APQN is used for an operation, a utility function is added
to select a specific APQN for usage with the CCA host library.
The CCA host library allows to set environment variables to override
the default CCA APQN selection. The environment variables are inspected
during CCA host library initialization only. To select a specific
domain for CCA, the CSU_DEFAULT_DOMAIN environment variable is set,
and then the CCA host library is un-loaded and re-loaded again.
Furthermore, the 'Cryptographic Resource Allocate' verb of the CCA
host library is used together with the 'Cryptographic Facility Query
function' verb to iterate over the crypto cards known by the CCA host
library, and to identify the desired crypto card based on its serial
number. That way, a specific APQN can be selected for use with
subsequent CCA verbs.
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>
Perform a cross check of the APQNs when the APQN association of a
secure AES key in the key repository is changed. When adding new APQNs,
or associating a new set of APQNs to a secure key, then the APQNs are
cross checked. If all associated APQNs are removed, then all currently
available APQNs are cross checked. If a master key mismatch is detected,
then the change is rejected.
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>
Perform a cross check of the APQNs when an existing secure AES key is
imported into the key repository. When a set of APQNs are associated to
the imported secure key, these APQNs are cross checked. If no APQNs are
associated to imported secure key, then all currently available
APQNs are cross checked. If a master key mismatch is detected, then
the key import is rejected.
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>
Perform a cross check of the APQNs when a secure AES key is validated.
When a set of APQNs are associated to a secure key, these APQNs are
cross checked. If a secure key is validated outside of the key repository,
or no APQNs are associated to a secure key inside the key repository,
then all currently available APQNs are cross checked. If a master key
mismatch is detected, then an error message is issued.
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>
