Generate an ephemeral sysext signing key, that is injected into the
image's sysext root of trust. All OS-dependent sysexts will be signed by
this key and the private key (stored in /tmp) will be discarded on SDK
container exit.
Signed-off-by: Daniel Zatovic <daniel.zatovic@gmail.com>
* sdk: Fix ephemeral key directory paths baked into container images
The SDK container build process was persisting temporary directory
paths for module signing keys into /home/sdk/.bashrc. This caused
all container instances to share the same ephemeral key location.
Fixed by:
- Runtime check in sdk_entry.sh to recreate stale temp directories
- Build-time cleanup in Dockerfiles to remove the variables
Each container instance now gets unique temporary directories.
Signed-off-by: Daniel Zatovic <daniel.zatovic@gmail.com>
* sdk_entry: use persistent module signing keys for unofficial builds
For official builds (COREOS_OFFICIAL=1), continue using ephemeral
temporary directories for module signing keys.
For unofficial/development builds, use a persistent directory at
/mnt/host/source/.module-signing-keys to preserve keys across
container restarts.
Signed-off-by: Daniel Zatovic <daniel.zatovic@gmail.com>
---------
Signed-off-by: Daniel Zatovic <daniel.zatovic@gmail.com>
Move module signing key to /tmp, so that it stays in RAM. Disable
shredding signing key after coreos-modules finishes, but rather shred it
after coreos-kernel finishes, so that out of tree modules (like ZFS from
upstream portage) can also use the key before it is shreded.
When started by the Flatcar core user, the SDK failed to use UID 500
because inside the SDK there already is the core user from nss-altfiles
with the same ID. This way, the SDK user was continuing with UID 1000
and had permission errors.
Allow to reuse an existing ID for the SDK user. However, this only
works when usermod doesn't find a process that uses this ID, and we had
a race between the SDK entry points called by "docker start" and by
"docker exec". The race is unwanted anyway because we don't want to
execute the commands while setup_board is still running. Solve it by
setting the entrypoint for "docker start" directly to "bash -l" in
"docker create" (this is also what the entry point does as last step:
sudo su -l).
The creation of the target version file failed:
/home/sdk/sdk_entry.sh: line 32: /build/amd64-usr/etc/target-version.txt: Permission denied
Use root permissions to create the file.
This change ensures the binpkg host is updated if the board (OS) version
differs from the SDK version.
This is to ensure /build/[arch] uses the correct binary package cache.
Signed-off-by: Thilo Fromm <thilo@kinvolk.io>
For execution of the compiled binaries in /build/arm64-usr we rely on
qemu-user binfmt emulation and have to tell it where the root is with
QEMU_LD_PREFIX because build systems don't chroot into /build/arm64-usr
themselves (which also works just by chance on amd64 because we have
similar glibc versions and so on). The env var setup was done in
/etc/profile.d/qemu-aarch64.sh but is now not read anymore since the
container runs the shell not as login shell.
Add the login options to the bash and su calls when starting the
container.
This change introduces a containerised SDK as a replacement for cork SDK
operations. It also simplifies versioning by removing the need for
manifest repos as well as usage of the "repo" tool by use of git
submodules for coreos-overlay and portage-stable.
The following feature scripts are added:
- run_sdk_container: Run a command in an SDK container, using the
current scripts repo + ebuild submodules.
current scripts repo + ebuild submodules.
- bootstrap_sdk_container / build_sdk_container_image: Bootstrap a new
SDK and create an SDK container from the resulting SDK tarball.
The following additions have been made to SDK scripts:
- setup_board: add --pkgdir parameter to use a custom binary packge
directory.
Signed-off-by: Thilo Fromm <thilo@kinvolk.io>
