This add the basic framework to allow the test suite to run. It takes a very long time
so it my not be practical to run in some cases (days in my case).
The ptest log format has not been verified.
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Variables PREFERRED_PYTHON_PATH and PYTHON3_PATH are set with
${PYTHON_EXECUTABLE}. For cross compile, ${PYTHON_EXECUTABLE} may point
to other path rather than standard dir such as /usr/bin. Then the
generated library file contains such path which should NOT. Update to
make variables PREFERRED_PYTHON_PATH and PYTHON3_PATH configurable to
fix buildpaths issue:
| WARNING: openscap-1.3.7-r0 do_package_qa: QA Issue: File
| /usr/lib/libopenscap.so.25.5.1 in package openscap contains reference
| to TMPDIR [buildpaths]
Signed-off-by: Kai Kang <kai.kang@windriver.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
There could be some false possitives (the script is far from perfect), so please
test it on your QA, I've only double checked with "git grep" (the script looks
only in parent directory).
@ ~/layers/meta-security $ /OE/extra-layers/meta-ros/scripts/check-patch-files.sh .
./recipes-ids/tripwire/files/add_armeb_arch.patch: not used in any recipe
./dynamic-layers/meta-python/recipes-security/fail2ban/files/0001-To-fix-build-error-of-xrang.patch: not used in any recipe
./recipes-scanners/clamav/files/fix2_libcurl_check.patch: not used in any recipe
./recipes-scanners/arpwatch/files/postfix_workaround.patch: not used in any recipe
./meta-tpm/recipes-tpm/libtpm/files/Use-format-s-for-call-to-dprintf.patch: not used in any recipe
./meta-tpm/recipes-tpm/libtpm/files/fix_signed_issue.patch: not used in any recipe
./meta-tpm/recipes-tpm/libtpm/files/Convert-another-vdprintf-to-dprintf.patch: not used in any recipe
./meta-tpm/recipes-tpm/swtpm/files/fix_lib_search_path.patch: not used in any recipe
./meta-tpm/recipes-tpm/swtpm/files/fix_fcntl_h.patch: not used in any recipe
./recipes-mac/AppArmor/files/disable_perl_h_check.patch: not used in any recipe
@ ~/layers/meta-security $ git grep add_armeb_arch.patch
@ ~/layers/meta-security $ git grep 0001-To-fix-build-error-of-xrang.patch
@ ~/layers/meta-security $ git grep fix2_libcurl_check.patch
@ ~/layers/meta-security $ git grep postfix_workaround.patch
@ ~/layers/meta-security $ git grep Use-format-s-for-call-to-dprintf.patch
@ ~/layers/meta-security $ git grep fix_signed_issue.patch
@ ~/layers/meta-security $ git grep Convert-another-vdprintf-to-dprintf.patch
@ ~/layers/meta-security $ git grep fix_lib_search_path.patch
@ ~/layers/meta-security $ git grep fix_fcntl_h.patch
@ ~/layers/meta-security $ git grep disable_perl_h_check.patch
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Create a wks.in that allows an out-of-the-box build of a bootable
USB image using systemd and the hash data as a separate device or
partition.
A focus here was to ensure we used proper GPT names and GPT types,
and the GPT UUIDs that are based on splitting the root hash.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
The prior commits create the separate hash so now it is time to update
the initramfs framework so that veritysetup, which is responsible for
binding the data and hash, is aware of when separate hash is in use,
and can react accordingly.
The added code follows the existing appended hash code style, but is
considerably smaller because it doesn't have the large case statement
that supports all possible identification schemes (label, UUID, ...).
With the root hash split in two to create the respective partition
UUIDs, we know exactly how to identify it, and the UUIDs used.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Export the dynamic build data for consumption in wic image generation.
It can either be included directly or manually parsed for useful chunks
in custom configurations people end up making.
For convenience, it is placed alongside the work-shared/dm-verity dir
where we already store the plain environment file and the veritysetup
formatting argument that was used.
There is a subtle thing going on here with respect to using an include,
which warrants a mention. The wic (wks.in) stuff only has access to
normal Yocto/OE/bitbake variables.
So, instead of a fragment, say if you had:
DM_VERITY_ROOT_HASH = "__not_set__"
and then later, did a:
d.setVar("DM_VERITY_ROOT_HASH", value)
after the image was built, and the hash was known - that seems sane.
But the problem is that once you do that, your variables are tracked
by default, and bitbake/lib/bb/siggen.py will be angry with you for
changing metadata during a build. In theory one should be able to avoid
this with BB_BASEHASH_IGNORE_VARS and "vardepsexclude" but it means more
exposed variables, and as much as I tried, I couldn't get this to work.
Creating a fragment with the dynamic data for inclusion avoids all that.
The wks template itself remains static, and hence doesn't trigger warns.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
There are essentially two ways for dealing with where to put the hash
data for dm-verity block integrity checks.
You can store both in a single partition, by using ~95% of the storage
space for the filesystem and the remaining 5% tail for the hash, or you
can use a completely separate partition (or even device) for storing the
hash data elsewhere.
Method A relies on using a hash offset argument during creation, which
is generally OK from a scripted use case but is error prone when run
from the command line and the offset calculated manually.
Method B has the advantage of using the basic partition/device
compartmentalization of the kernel to ensure the fs data doesn't
overwrite the hash or vice versa. It takes any possible errors due to
math miscalculations completely off the table.
At the moment, our current support is hard coded to only support the
offset method A. Here we add support for separate hash as per B.
As multiple partitions are now in play, we use the UUID creation
standard adopted by the systemd/verity community which implicitly links
the root and hash partitions by splitting the top roothash in two for
the UUIDs of the components.
This change optionally creates the separate hash file but no examples
use it yet. Further commits will implement an example.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
We already have this directory to save the environment variable settings
so they can be copied into the initramfs for runtime setup.
There are quite a few veritysetup args, and the nature of storing the
hash data after the filesystem data in an "oversized" partition can be
error prone due to rounding, fencepost errors, etc.
Save a copy of what we used for ease of debug inspection, and for basic
cut and paste use in experimentation and tweaking.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
In making changes to the existing veritysetup arg list, it is harder to
see what the proposed change is since they are are glued together on one
long line. Break them up so reviewing future unified diffs will be more
easy to visually parse.
This also makes it easier to temp. dump the args to a file for debugging.
In theory this should have no functional change.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Without these one line descriptors and their associated marker prefix,
the output from "wic list images" only shows they are available as a
choice but w/o any description
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
There is new patch-status QA check in oe-core:
https://git.openembedded.org/openembedded-core/commit/?id=76a685bfcf927593eac67157762a53259089ea8a
This is temporary work around just to hide _many_ warnings from
optional patch-status (if you add it to WARN_QA).
This just added
Upstream-Status: Pending
everywhere without actually investigating what's the proper status.
This is just to hide current QA warnings and to catch new .patch files being
added without Upstream-Status, but the number of Pending patches is now terrible:
0 (0%) meta-parsec
N/A (0%) meta-hardening
1 (100%) meta-integrity
15 (68%) meta-tpm
27 (61%) meta-security
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
