"Failed to dissect image: connection timed out" messages have been
appearing sporadically in mkosi CI. Let's enable debug logging to
help figure out why.
Let's make sure we're testing unprivileged builds properly. Usage
of SourceFileTransfer= and SourceFileTransferFinal= are removed as
they were dropped by mkosi. SourceFileTransfer=mount is now the
default in mkosi so behavior for the build script is unchanged. We
stop copying sources in the final image until mkosi adds support
for virtiofs.
`github.event.issue.pull_request` is an object, not a boolean.
This is the root cause of why the step that is supposed to remove labels
is always skipped. Having this condition in place is not necessary since
the workflow is run on the `pull_request_target` event.
(The one case that is left unchanged is '< <(subcommand)'.)
This way, the style with no gap was already dominant. This way, the reader
immediately knows that ' < ' is a comparison operator and ' << ' is a shift.
In a few cases, replace custom EOF replacement by just EOF. There is no point
in using someting like "_EOL" unless "EOF" appears in the text.
Due to the limitation of `GITHUB_TOKEN` when running workflows from forks,
it's required to split the `development_freeze` workflow in two.
* First workflow will run on the `pull_request` trigger and save the PR
number in the artifact. This workflow is running with read-only permissions
on `GITHUB_TOKEN`.
* Second workflow will get triggered on `workflow_run`. It will be run
directly in the `systemd/systemd` context and can get permission to be
able to create comments on PR.
GITHUB_TOKEN limitations:
* https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token
GitHub Security Labs Article - How to correctly and safely overcome GITHUB_TOKEN limitations:
* https://securitylab.github.com/research/github-actions-preventing-pwn-requests/
This gives us some nice test coverage for secure boot enrolling and the
stub secure boot workound. The authenticated EFI variables are already
created by mkosi, all we need to do is request secure boot to be used.
It's still useful to test the EFI handover logic in systemd-boot.
We use a mkosi.prepare script to install a newer python and update
the system to use it.
We also add the necessary deps for ukify to the mkosi configs.
CentOS Stream 8 is dropped from CI because its python version is too
old (3.6) to be able to run ukify.
Let's make sure we're testing with the latest changes in mkosi. This
includes both the switch to systemd-repart and ukify, making sure we
get extra testing coverage for those components.
This also drops options from the centos config that have been removed
in the newer mkosi.
For some reason idmapping runs into some issues so we disable it for
now.
Meson started warning when 'setup' is not used:
WARNING: Running the setup command as `meson [options]` instead of `meson setup [options]` is ambiguous and deprecated.
Also add more quoting in output to make the message clearer.
This erase_obj() machinery looks like voodoo and creates an awful lot of
noise as soon as we get back to building with -O0. We can do this in a
more simple way by introducing a struct that holds the information we
need on cleanup. When building with optimization enabled, all this gets
inlined and the eraser vanishes.
- Mention "/please-review" in the contributing guide
- Remove "needs-rebase" on push
- Don't add "please-review" if a green label is set
- Don't add please-review label to draft PRs
- Add please-review when a PR moves out of draft
When a pull request is opened/updated, add "please-review" and
remove a few other labels.
When a comment is made with /please-review on a PR. Add the
"please-review" label to the PR.
Rather than passing seeds up to userspace via EFI variables, pass seeds
directly to the kernel's EFI stub loader, via LINUX_EFI_RANDOM_SEED_TABLE_GUID.
EFI variables can potentially leak and suffer from forward secrecy
issues, and processing these with userspace means that they are
initialized much too late in boot to be useful. In contrast,
LINUX_EFI_RANDOM_SEED_TABLE_GUID uses EFI configuration tables, and so
is hidden from userspace entirely, and is parsed extremely early on by
the kernel, so that every single call to get_random_bytes() by the
kernel is seeded.
In order to do this properly, we use a bit more robust hashing scheme,
and make sure that each input is properly memzeroed out after use. The
scheme is:
key = HASH(LABEL || sizeof(input1) || input1 || ... || sizeof(inputN) || inputN)
new_disk_seed = HASH(key || 0)
seed_for_linux = HASH(key || 1)
The various inputs are:
- LINUX_EFI_RANDOM_SEED_TABLE_GUID from prior bootloaders
- 256 bits of seed from EFI's RNG
- The (immutable) system token, from its EFI variable
- The prior on-disk seed
- The UEFI monotonic counter
- A timestamp
This also adjusts the secure boot semantics, so that the operation is
only aborted if it's not possible to get random bytes from EFI's RNG or
a prior boot stage. With the proper hashing scheme, this should make
boot seeds safe even on secure boot.
There is currently a bug in Linux's EFI stub in which if the EFI stub
manages to generate random bytes on its own using EFI's RNG, it will
ignore what the bootloader passes. That's annoying, but it means that
either way, via systemd-boot or via EFI stub's mechanism, the RNG *does*
get initialized in a good safe way. And this bug is now fixed in the
efi.git tree, and will hopefully be backported to older kernels.
As the kernel recommends, the resultant seeds are 256 bits and are
allocated using pool memory of type EfiACPIReclaimMemory, so that it
gets freed at the right moment in boot.
