Other tools may need to process the configuration-unique id. Provide a
machine readable format by writing to a YAML file containing a `cuid`
entry and optionally an `add` entry. New CLI options `--format` and
`--output` are introduced for this. Currently, only the output format
`yaml` is supported.
Reviewed-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Replace local ifs_orig variables in different functions by a single
global IFS_ORI variable. This will reduce the risk of missing a local
saving and restore of the original IFS.
Reviewed-by: Michael Storzer <MSTORZER@de.ibm.com>
Signed-off-by: Joern Siglen <siglen@de.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add `pvsecret` a tool to create, add, list, and delete Ultravisor
secrets. `pvsecret` uses the functionality from the pv-crate
to provide an command line tool to manage the secrets.
Add a new target group PV_TARGETS in rust/Makefile that additionally
requires openssl and libcurl as pv with the feature "request" uses
openssl and libcurl fearures.
Acked-by: Jan Höppner <hoeppner@linux.ibm.com>
Acked-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
[hoeppner@linux.ibm.com: Adapt man pages and help output]
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add a `pv` crate that bundles useful functions and structs for creating
requests like `Attestation`, `Add Secret`, or even `Boot` a.k.a.
Secure Execution Image.
Note pv includes a subcrate `openssl_extensions` that (temporarily)
bundles some needed `openssl-rust` functionalities that are not
upstream yet. The plan is to remove these, when they become
upstream.
The pv crate has multiple features:
* request - code to generate requests
* uvsecret - code to access the UV-secret api
with request enabled also generating requests is
possible
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Acked-by: Jan Höppner <hoeppner@linux.ibm.com>
Acked-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The rust integration into the s390-tools build system consists of the
following steps:
- Add a subdirectory for the rust code.
- Add a Makefile that forwards rust builds to `cargo`.
- Add a `utils` crate for rust code in s390-tools.
- Add rust stuff for dotfiles:
- gitignore
- editorconfig
- codespellrc (while at it, add an ignore file)
With cargo the rust ecosystem has its own build system which also is
responsible to resolve rust dependencies via downloading the dependencies
from (default) crates.io and discover the source files. Therefore, the
Makefile just calls `cargo build` to forward the build to cargo.
If a rust crate does not require external dependencies, users might call
rustc directly.
A simple `make` will build all the rust targets as well (with --release
specified). Also `make install` will work as usual.
A few Makefile configuration variables are introduced for rust/Cargo:
- HAVE_CARGO (default 1) to toggle the build of rust code using cargo
- CARGOFLAGS to add custom cargo flags, e.g. --offline
- CARGO Cargo binary location defaults to
$(where cargo)
A new global make target is defined to get the current s390-tools
version:
$ make version
2.28.0
rust/Makefile also has the `print-rust-targets` target to print all rust
directories/crates that should be shipped/installed.
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Reviewed-by: Jan Höppner <hoeppner@linux.ibm.com>
Acked-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
IBM Secure Execution guests may want to share additional secrets with
the Ultravisor in a secure manner. For this the concept of secret
requests and three new Ultravisor-calls were introduced.
Add support to genprotimg to prepare an Secure Execution image with the
requirement that add-secret requests must provide an extension secret
that matches the customer communication key (CCK) derived extension
secret.
Reviewed-by: Steffen Eiden <seiden@linux.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
`genprotimg` can be useful on non-s390x architectures such as x86 or
arm. Therefore add `genprotimg` to the non-s390x target list.
How to build genprotimg on a non-s390x system (s390x cross-compiler
required)
$ # Build and install /usr/bin/genprotimg
$ make -C genprotimg
$ make install -C genprotimg
$ # Build and install the genprotimg bootloaders
$ make -C genprotimg/boot HOST_ARCH=s390x CROSS_COMPILE=s390x-linux-gnu-
$ make install -C genprotimg/boot HOST_ARCH=s390x CROSS_COMPILE=s390x-linux-gnu-
Reviewed-by: Steffen Eiden <seiden@linux.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
A subset of s390 tools can be useful on non-s390x architectures such as
x86 or arm. Limit the build targets for these architectures with
'pvattest' and 'libpv' as the first candidates.
A cross compilation on x86 for s390x will still build the entire package
provided that the HOST_ARCH variable is set properly:
$ make HOST_ARCH=s390x CROSS_COMPILE=s390x-linux-gnu-
Cross compilation on s390x for x86 will limit the build targets as
described:
$ make HOST_ARCH=x86_64 CROSS_COMPILE=x86_64-linux-gnu-
Co-developed-by: Jan Höppner <hoeppner@linux.ibm.com>
Reviewed-by: Steffen Eiden <seiden@linux.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
Introduce `BUILD_ARCH` and `(CC|LINK|...|OBJDUMP)_FOR_BUILD` variables
in order to properly support the build of tools that generate code or
data during the build process. Replace existing variables `HOSTCC` with
`CC_FOR_BUILD` and `HOSTCFLAGS` `CFLAGS_FOR_BUILD`. The Makefile
variables for the `HOST_ARCH` are unchanged.
Reviewed-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
`pkg-config` is a well established tool and all of our required
libraries do provide .pc files. Therefore let's declare `pkg-config` as
required and use it. In addition, remove now useless code.
Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
Reviewed-by: Steffen Eiden <seiden@linux.ibm.com>
Reviewed-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Steffen Eiden <seiden@linux.ibm.com>
changes in opencryptoki setup do require some modifications:
- "pkcsconf -mlist" does no longer work in a combined format
- config files have changed
- ep11info was not yet collected
Signed-off-by: Joern Siglen <siglen@de.ibm.com>
Reviewed-by: Ingo Franzki <ifranzki@de.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
generalize the collection step name from "docker" to "container host"
initial version of adding data collection for OCP.
all log file content might be too much for most installations
Reviewed-by: Alexander Klein <alkl@de.ibm.com>
Reviewed-by: Mario Held <mario.held@de.ibm.com>
Reviewed-by: Mike Storzer <mstorzer@de.ibm.com>
Signed-off-by: Joern Siglen <siglen@de.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
some versions of /bin/dash do interpreted our commands different, which
causes a variable failure and termination of the script.
e.g. a new line char "\n" will split the cmd_type to a multiple line variable
not working with the followup commands. adding the head command does avoid
multiline variables now.
Problem found in Ubuntu 20.4 and some older Ubuntu versions
Reviewed-by: Mario Held <mario.held@de.ibm.com>
Signed-off-by: Joern Siglen <siglen@de.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
we do miss a simple way to see the dbginfo.sh version used by the
customer for the debug generation. saving the version now to dbginfo.log
Reported-by: Mike Storzer <MSTORZER@de.ibm.com>
Reviewed-by: Mario Held <mario.held@de.ibm.com>
Signed-off-by: Joern Siglen <siglen@de.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
This can now include /lib/modprobe.d/10-unsupported-modules.conf
Strictly speaking, modprobe would only consider *.conf files inside
those directories, but for consistency with the already existing
collection of /etc/modprobe.d instead of /etc/modprobe.d/*.conf,
do the same for the added missing locations.
Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The "detour" with NUL terminated records ensures that sorting
works as expected for environment variables with values containing
one or more lines and thus '\n' as regular record separator.
Reviewed-by: Joern Siglen <siglen@de.ibm.com>
Signed-off-by: Steffen Maier <maier@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
On several distributions `pandoc` is not available via the default
repositories, and thus not available in the build environments for the
distribution packages. That means, the man page can't be bundled along
with the packages generated for those distributions.
But since this is a valuable asset for some users, instead of requiring
`pandoc` in order to have a man page be generated during the build, so it
can be installed, bundle a pre-cooked version that corresponds to the
current version of the `README.md` file. This way, the man page can always
be packaged, and is now always installed, even if `ENABLE_DOC` is set to
`0` (the default).
This also means, whenever the `README.md` file is changed, the bundled
man page needs to be regenerated, so it stays in sync. As a safeguard
we also add a checksum of the `README.md` file that is regenerated along
with the man page. This checksum is tested even when `pandoc` is not
available, and the user is notified whenever it runs out of sync (with a
hint as to how to remedy it).
Nothing changes for the compile/installation workflow, if `ENABLE_DOC` is
set to `1`.
Suggested-by: Jens Remus <jremus@linux.ibm.com>
Reviewed-by: Steffen Maier <maier@linux.ibm.com>
Signed-off-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
'which' tool is packaged separately from other core tools and there will
likely be scenarios where this check will fail because 'which' is
unavailable.
The "type" is builtin itself and should solve this problem.
For a built in command, we will not suppress error out -> removing 2>&1.
On this replace - in call_run_command - get cmd_type as variable only once
Reported by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Joern Siglen <siglen@de.ibm.com>
Reviewed-by: Mario Held <mario.held@de.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Steffen Eiden