Age | Commit message (Collapse) | Author |
|
During installation, TPM 1.2 or 2.0 have to be chosen explicitly via
the "tpm" env variable. Detecting whether a /dev/tpm0 supports TPM 1.2
or 2.0 turned out to be
tricky (https://github.com/intel/tpm2-tools/issues/604) and probably
isn't worth the effort and potential error cases.
Conceptually TPM 2.0 supports is similar to the one for 1.2, with one
exception: because it is possible to use NVRAM without taking
ownership and taking ownership with known passwords wouldn't provide
any advantages, the TPM 2.0 support code skips that step.
Testing switches to swtpm2 for both the existing TPM1.2 test and the
new TPM2.0 test. It just gets parameterized differently.
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
|
|
When we failed to retrieve a password, zapping the empty keyfile led
to dd being called with bs=0, triggering an error. Using count=0 is
fine. While at it, the regular dd output gets silenced because it is
irrelevant and might even expose some undesirable information (length
of password).
Not finding a password was not reported well. Now there is an explicit
error message about it.
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
|
|
This gets done for the sake of consistency with other
layers (meta-security, meta-measured) and the naming of the kernel
config files.
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
|
|
Dumping the keyfile with "od" was done only for debugging
and accidentally leaked the key.
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
|
|
Having to write custom Python code in each recipe which needs to check
for optional components (= other recipes or bbclasses) leads to less
readable recipes. A common utility class can cover both and, when
something is missing, can provide a single error message that lists
all missing components.
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
|
|
In the revised image-dsk.bbclass, creating the second UEFI combo app
for internal media is optional. As the installer image itself is never
going to be installed, we can skip creating and installing that second
combo app.
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
|
|
Most of the code was already moved to meta-intel. Once "[PATCH]
uefi-comboapp.bbclass: support multiple UEFI combo apps + fixes" is
also merged, we can create both versions of the UEFI combo app (for
internal and removable media) with uefi-comboapp.bbclass, including
Secure Boot signing.
We keep the image-dsk.bbclass. Its usage is optional (as before) and
enables UEFI combo app plus the refkit disk layout. This way
uefi-comboapp.bbclass (and thus meta-intel) are only required when
really used.
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
|
|
This merges PR #143, PR #222, PR #235, PR #242.
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
|
|
The usrmerge patches are now in OE-core. The corresponding changes in
refkit must be removed together with updating to that version to avoid
build breakages (like "/usr/usr/lib/ld-linux-x86-64.so.2: No such file
or directory" in gobject-introspection).
* bitbake 8d0a76f...4a14b44 (33):
> knotty: Drop task prefix of PLAIN log messages
> BBHandler: Remove old style bb.data.setVar() syntax usage
> server/xmlrpc: Add Heartbeat event support
> event: Queue offline events for the UI
> server/process: Fix waitEvent() calls with 0 timeout
> data: Micro performance optimisation tweak
> cooker: Use multiple BuildStarted events for multiconfig
> bitbake: Add MultiConfigParsed event
> bitbake-user-manual: Removed and replaced broken link
> bitbake-user-manual: Replaced bad link
> npm fetcher: fix unknown variable name.
> cache: don't insert PN into PACKAGES
> toaster: test 'commit' first in get_vcs_reference
> toaster: large package set breaks sqlite query
> toaster: Add distro selection support
> toaster: git clone progress bar
> toaster: address Django-1.10 API deprecations
> bitbake-selftest: add bb.tests.event to bitbake-selftest
> tests: create unit tests for event module
> event: remove mapping for deleted event handlers
> fetch: fix handling of files with incorrect checksums from a premirror
> event: drop some unused events
> toaster: noweb should init database
> toaster: get_last_build_id not called correctly
> toaster: add getMessage to MockEvent
> toaster: fail on layers with sub-layer
> toaster: add ID's to build menu links
> toaster: add ID's to navigation links
> bitbake-user-manual: Updated BBLAYERS_FETCH_DIR variable description
> cooker: ensure graceful exit after exception during BuildCompleted handler
> cooker: fix always loading cache on every UI start with memres
> bitbake: runqueue: multiconfig fix
> bitbake:process: flush stderr/stdout to log
* openembedded-core de79149...7dd5dfc (80):
> oeqa/tinfoil: Improve test_wait_event for race issues
> staging: Ensure a clean recipe sysroot removes addto_recipe_sysroot stamps
> oeqa/sdk: Replace buildiptables for buildlzip tests
> testimage: Use the renamed buildlzip
> oeqa/runtime: Replace buildiptables for buildlzip on runtime tests
> mirrors.bbclass: remove stale lsof ftp mirrors
> lsof: update SRC_URI
> lsof: minor recipe cleanup
> image_types: fix kernel target on elf's image dependencies
> linuxloader.bbclass: add musl libc support
> vulkan: RRECOMMEND mesa drivers
> mesa, gstreamer: Add "vulkan" DISTRO_FEATURE
> gstreamer1.0-plugins-bad: Add vulkan PACKAGECONFIG
> assimp: Add as dependency of vulkan-demos
> vulkan: Upgrade 1.0.39.1 -> 1.0.51.0
> perl: Support musl-x32 build
> grub-efi: Support musl-x32
> gnu-efi: Support musl-x32 build
> siteinfo.bbclass: Support musl-x32
> insane.bbclass: Support musl-x32
> mesa: etnaviv: fix shader miscompilation with more than 16 labels
> ovmf: Fix build with toolchain defaulting to PIE
> security_flags.inc: Do not build gcc for powerpc with PIE defaults
> gstreamer1.0-plugins-bad: Fix missing library with bcm egl
> libunwind: We set -fPIE in security flags now if gcc is not configured for default PIE
> sysklogd: Improve build and fix runtime crash
> gcc: Link libssp_nonshared.a only on musl targets
> gcc7: Enable static PIE
> distutils,setuptools: Delete use of SECURITY_NO_PIE_CFLAGS
> security_flags.inc: Delete pinnings for SECURITY_NO_PIE_CFLAGS
> gcc: Introduce a knob to configure gcc to default to PIE
> base: Add MultiConfigParsed handler to deal with unstable build signatures
> image.bbclass: create root symlinks in nativesdk target sysroot
> insane.bbclass: Add package QA check for merged /usr.
> image: create symlinks needed for merged /usr
> systemd: changes to support merged /usr
> cross.bbclass: merged /usr support
> bitbake.conf: support for merged usr with DISTRO_FEATURE usrmerge
> speex: update SRC_URI
> avahi-ui: reduce local pending patches
> mirrors: Add HTTP mirrors for ftp://sourceware.org
> local.conf.sample: drop image-swab reference
> ltp: add acl, attr, curl and util-linux runtime dependencies
> ltp: Reduce local Pending patches
> ltp: syscalls/add_key02: fix for nonempty NULL payload
> libgfortran: Add missing fincludes
> libgfortran: Add missing dependency gcc-cross
> systemd: Do not use xlocale.h
> mesa: Upgrade to 17.1.4 release
> mesa: Avoid platform probing when building without EGL
> sanity.bbclass: fix AttributeError in mirror format checks
> oe-pkgdata-util: package-info: Allow extra variables to be displayed
> expat: upgrade to 2.2.1
> grep: upgrade to 3.1
> classes/populate_sdk_base: Fix SDK manifest generation
> valgrind: Remove -no-pie from cflags
> icu: Fix build with glibc 2.26
> epiphany: Fix build errors when compiling with security flags
> qemu: Replace use of struct ucontext with ucontext_t
> strace: upgrade to 4.17
> valgrind: Fix build with glibc 2.26
> bluez: Correct the timer count for bcm43xx firmware download
> binutils: update SRCREV to fix powerpc gold link bug
> yocto-compat-layer.py: make signature check code reusable
> yocto-compat-layer.py: allow README with suffix
> yocto-compat-layer.py: add test_world
> yocto-compat-layer.py: apply test_signatures to all layers
> yocto-compat-layer.py: tolerate broken world builds during signature diff
> yocto-compat-layer.py: avoid adding layers more than once
> sysstat:11.5.5 -> 11.5.6
> openssl: Upgrade 1.0.2k -> 1.0.2l
> libepoxy: Upgrade 1.4.2 -> 1.4.3
> gtk+3: Update the patches to work with old versions of patch
> gtk+3: Upgrade 3.22.15 -> 3.22.16
> gtk+3: Update UPSTREAM_CHECK_REGEX
> cmake: Use find_program if find_host_program is not available
> insane: remove obsolete gcc 4.5 check
> sanity.bbclass: remove ASSUME_PROVIDED checks that can't succeed
> meta/lib/oe/sdk.py: support added for executing pre-target commands
> mkefidsk: fix bash/dash shell quoting problem
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
merge: update
|
|
Switch to using the C-based implementation of refkit-ostree in the
refkit ostree initramfs module for parsing the boot loader config
files and picking the latest ostree deployment to boot into.
Split out refkit-ostree (which is a subset of refkit-ostree-update
that does not depend on libostree) into a (refkit-ostree-)initramfs
subpackage
Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
|
|
The OSTree recipe is taken from meta-flatpak, because that is what is
already in intel-iot-refkit. The integration into the build process
relies on using wic. Special support is provided for updating the UEFI
combo app.
This commit combines the initial work done by Krisztian Litkey with
various cleanup changes by Patrick Ohly. It got squashed because the
entire history would be confusing.
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
|
|
The initramfs-framework debug module should not be needed in
development images and better gets avoided (less code is better).
To enable debug support in development mode, use:
IMAGE_FEATURES_append_pn-refkit-initramfs = " debug"
IMAGE_FEATURES_append_pn-refkit-initramfs-development = " debug"
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
|
|
Prepare the root symlinks required for runtime at the time of rootfs creation.
The assumption is that in usrmerged distro, no package installs files in
/bin,/sbin and /lib* folders.
Upstream Patches:
http://lists.openembedded.org/pipermail/openembedded-core/2017-February/133166.html
Signed-off-by: Amarnath Valluri <amarnath.valluri@intel.com>
|
|
Signed-off-by: Tuomas Katila <tuomas.katila@intel.com>
|
|
Forcing developers to choose between production and development builds
was non-standard (thus tripping up new developers) and inflexible
(couldn't build product and development images at the same time).
The new image-mode.bbclass replaces that with a per-image IMAGE_MODE
variable that can be set as desired in local.conf for existing image
recipes or fixed on a specific value in specific images. It also
customizes /etc/motd in the images, just like the refkit-specific code
did before.
The default (in our local.conf.sample) is to build images in
development mode. This is a bit more relaxed than the approach we
inherited from Ostro OS where a developer was explicitly forced to
choose.
Because setting the Secure Boot signing keys no longer depends on the
.inc files, the default development keys can be moved to
meta-refkit-core, where they are used as default for IMAGE_MODE !=
production.
It is possible that the same build may now need an refkit-initramfs in
development mode (= default dm-verity keys) and one in production
mode. This is solved by providing refkit-initramfs in different variants,
generated automatically using image-mode-variants.bbclass. For this to
work, we have to set valid refkit modes globally.
Extra care is needed to avoid setting IMAGE_MODE and IMAGE_MODE_VALID
themselves globally: the values that are valid for refkit images are
not valid for other images, like core-image-minimal. While that
particular image doesn't do anything with IMAGE_MODE, others might.
Therefore we set REFKIT_IMAGE_MODE[_VALID] globally and copy to the
values checked by the helper classes in the refkit images.
The refkit images use the REFKIT_IMAGE_MODE set in our
local.conf.sample, which may vary in actual builds. Testing continues
to use that because if already built in the right mode, there's no
need to rebuilt an image with a fixed mode.
If someone wants, they now can also built images with a specific
mode that also gets included in the resulting image files (for example,
refkit-image-computervision-development).
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
|
|
This makes it possible to easier to build images without the feature
because in that case, there is no need to provide a key.
initramfs-framework-refkit-dm-verity.bb makes no sense without a key
and now removes itself from a world build when no key is set. Trying
to use it will then trigger a dependency error.
refkit-initramfs.bb cannot check whether the
initramfs-framework-refkit-dm-verity is available and thus continues
to check the DISTRO_FEATURES to determine whether it should enable
dm-verity.
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
|
|
These changes ensure that the new layers can be used in combination
with Poky (i.e. no .bbappends for recipes that might not be present)
without changing the signature of existing recipes unless the change
gets requested explicitly in settings file besides bblayers.conf.
In other words, the layers should be Yocto Compatible 2.0 and
currently pass even the enhanced yocto-compat-layer.py tests.
Changes that were previously considered "distro configuration" are now
available also without using DISTRO=refkit, by including the new
meta-refkit-core/conf/distro/include/refkit-config.inc file *and*
setting certain distro features (currently "refkit-config",
"refkit-computervision", and "refkit-firewall"). Without those distro
features, refkit-config.inc doesn't change anything. This allows users
of the config to pick and choose what they want, and it matches the
mechanism used to select .bbappend content.
The technique of turning that DISTRO_FEATURE also into an override and
making append/prepend changes depend on that is used to avoid
signature changes in unless explicitly configured.
To avoid world build breakages, recipes in meta-refkit-core must be
careful about their dependencies because meta-refkit-core only has a
hard dependency on OE-core. By default, the availability of optional
recipes is detected by meta-refkit-core/conf/layer.conf by checking
which layers have been added.
Dangling .bbappends get avoided by moving the changes into the
refkit-conf.inc file. .bbappends for layers besides OE-core can't be
in meta-refkit-core. They can be added to dedicated layers where the
layer that the .bbappend applies to is a hard dependency. The
advantage is that this does not depend on the ordering of layers in a
bblayers.conf file. The alternative would be the technique used by
meta-freescale, where the layer.conf checks which layers have already
been added and then extends BBFILES accordingly.
Finally, bmap-tools-deploy.bbclass gets conditionally imported via
bmap-tools_%.bbappend as a last resort because the other two
approaches would not have worked. Currently this only works when using
"inherit" and a .bbclass; the plan is to make the same work in bitbake
also for the more natural "require" plus .inc.
Adding layers may change the content of
packagegroup-tools-interactive.bb because it adapts dynamically to
what is available. This is considered "Yocto Compatible 2.0", but may
trigger a false postive in yocto-compat-layer.py in certain scenarios
(meta-refkit-core in the base configuration, then some layer (like
meta-oe) is tested that meta-refkit-core uses optionally -> meta-oe
fails the "signature unchanged" test although it isn't faulty).
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
|
|
layers
The intention is to make it simpler for other projects to use content
from intel-iot-refkit without having to use the entire distro. This
first commit is good enough to keep building the refkit distro and
just moves files around without modifying them. Further work is needed
to make the individual pieces also functional stand-alone.
Separate profile layers get introduced and define their dependencies,
because then existing tooling (layer index, Toaster,
yocto-compat-layer.py) will be able to set up a project using them
together with these dependencies.
The meta-refkit-core layer is meant to be more flexible and does not
enforce the use of any layers besides OE-core. At the moment there are
probably still parse errors (due to .bbappends) or build errors
(missing dependencies) when layers are missing. This will be addressed
separately on a case-by-case basis.
The meta-refkit distro layer is meant to have just a minimal distro
configuration file which includes files from the other layers, plus
the project-specific content:
- local.conf and bblayers.conf samples
- the "supported recipes" list, which gets maintained for the distro and
not individually for each layer
- selftests which depend on the exact project configuration
This new approach gets documented in the doc/introduction.rst file, in
addition to explaining a bit more the benefit of using the
intel-iot-refkit and its distro as-is.
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
|