| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
Fixes oss-fuzz#51887 (https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=51887).
Fixes #24833.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The compiler may decide computations like these are not doing anything
and decide to optimize them away. This would defeat the whole fuzzing
exercise. This macro will force the compiler to materialize the value
no matter what. It should be less prone to accidents compared to using
log functions, which would either slow things down or still optimize the
value away (or simply move it into the if branch the log macros create).
The benefit over assert_se would be that no requirement is made on the
value itself. If we are fine getting a string of any size (including
zero), an assert_se would either create a noisy compiler warning about
conditions that would alawys be met or yet again optimize the whole
thing away.
|
|
|
|
| |
This is not needed anymore, so do it the proper way now.
|
| |
|
|\
| |
| | |
boot: Try to detect overlapping PE sections
|
| |
| |
| |
| |
| | |
This should help finding the cause of boot failures because of badly
assembled unified kernel images.
|
| |
| |
| |
| |
| |
| | |
It only really makes sense to fetch the location from either one of
these fields, depending on whether we are looking at an in-memory
(relocated) or a file PE image.
|
| | |
|
| |
| |
| |
| |
| | |
We can derive the public key from the private key, so let's do that, to
make things a bit easier.
|
| | |
|
| | |
|
|\ \
| | |
| | | |
measure: some tweaks
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Let's separate the PE section options in the --help text to make clearer
that they are about PE sections, and thus make things less confusing
regarding the cryptic names. Specifically, there's now a separate
section in the --help text that looks like this:
<snip>
UKI PE Section Options: UKI PE Section
--linux=PATH Path Linux kernel image → .linux
--osrel=PATH Path to os-release file → .osrel
--cmdline=PATH Path to file with kernel command line → .cmdline
--initrd=PATH Path to initrd image → .initrd
--splash=PATH Path to splash bitmap → .splash
--dtb=PATH Path to Devicetree file → .dtb
--pcrpkey=PATH Path to public key for PCR signatures → .pcrpkey
</snipe>
(The section title is underlined, like we usually do it)
I think separating this out, and organizing the section name in tabular
form emphasizes nicely where this switches get their name from and what
they mean.
Hopefully addresses concerns from
https://github.com/systemd/systemd/pull/24458#discussion_r967052720 in a
diferent way.
(Also dropped a hint regarding DER format for public key. it's simply
wrong, we use PEM like everyone else on Linux. Outside of Java land DER
isn't popular, so we don't need to mention it here in the --help text,
man page should be enough.)
|
| | |
| | |
| | |
| | | |
https://github.com/systemd/systemd/pull/24458#discussion_r966941104
|
| | |
| | |
| | |
| | |
| | |
| | | |
We forgot to conditionalize this on pcrsig/pcrpkey too. So if you have
ne creds or sysext configured we actually wouldn't pass pcrsig/pcrpkey
along. Let's fix that.
|
| | |
| | |
| | |
| | |
| | |
| | | |
The kernel PE image version can be used to detect support for this
feature, allowing us to prefer the generic code of the deprecated EFI
handover protocol.
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
Apparently, this is not needed when red zones are disabled and we do
that.
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | | |
We could try to relocate these but that is probably not needed. So far
we have not been bitten by this in the real world and kernels we boot
likely already support this anyway.
|
| | |
| | |
| | |
| | |
| | |
| | | |
The boot params passed to the kernel only has to be one page in size
and the size of the setup header has to be calculated as it depends on
the boot protocol version supported by the kernel.
|
|/ /
| |
| |
| |
| |
| |
| |
| | |
The kernel x86 boot protocol does not expect this value to be set when
using EFI handover protocol. If the stub is loaded above 4G we would
end up discarding the high bits, breaking boot.
Fixes: #24707
|
| |
| |
| |
| |
| |
| |
| | |
Relying on symbol aliasing seems to be rather unreliable. Instead just
use some light #ifdefery.
Fixes: #24630
|
| |
| |
| |
| |
| |
| |
| |
| | |
This way we can use it directly in measure.c, and thus remove a bit of
redundant code.
OpenSSL prefers uppercasing the MD names, others don't hence let's be
lenient here.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
Let's say what we actually measure, not what into (which is obvious
anyway).
This is generally more descriptive, but also good for later work that
allows measuring the boot phase too.
|
|\ \
| | |
| | | |
Use ASSERT_PTR more
|
| |/ |
|
|/
|
|
| |
Fixes CID#1497847.
|
|
|
|
|
|
|
|
|
|
| |
Pick up the two new sections in sd-stub and pass them as initrds into
the booted kernels, where they'll show up as
/.extra/tpm2-pcr-signature.json and /.extra/tpm2-pcr-public-key.pem in
the initrd file system.
The initrd is then supposed to pick these files up from there and save
them at a place that will survive into the host OS.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These aren't wired up yet to do anything useful. For now we just define
them.
This sections are supposed to carry a signature for expected
measurements on PCR 11 if this kernel is booted, in the JSON format
"systemd-measure sign" generates, and the public key used for the
signature.
The idea is to embedd the signature and the public key in unified
kernels and making them available to userspace, so that userspace can
easily access them and enroll (for which the public key is needed) or
unlock (for which the PCR signature is needed) LUKS2 volumes and
credentials that are bound to the currently used kernel version stream.
Why put these files in PE sections rather than just into simple files in
the initrd or into the host fs?
The signature cannot be in the initrd, since it is after all covering
the initrd, and thus the initrd as input for the calculation cannot
carry the result of the calculation. Putting the signature onto the root
fs sucks too, since we typically want to unlock the root fs with it,
hence it would be inaccessible for it's primary purpose then.
The public key could be in the initrd or in the root fs, there's no
technical restriction for that. However, I still think it's a good idea
to put it in a PE section as well, because this means the piece of code
that attaches the signature can also attach the public key easily in one
step, which is nice since it allows separating the roles of the
kernel/initrd/root fs builder, and the role of the signer, and the
former doesn't have to have knowledge about what the latter is going to
add to the image.
Note that the signature section is excluded from the TPM measurements
sd-stub does about its resource sections, since – as mentioned – it's
the expected output of the signing operation whose input are the
measurements, hence it cannot also be input to them. The public key
section is included in the measurements however.
|
|
|
|
|
|
|
| |
Let's add simple helpers for passing data blobs from the stub into the
booted kernel as initrds that are generated on-the-fly.
(Note used yet, a later commit will make use of this)
|
|\
| |
| | |
support for signed TPM2 PCR policies in cryptsetup/cryptenrolls/credentials
|
| | |
|
|/
|
|
|
|
| |
Prompted by:
https://github.com/systemd/systemd/pull/24351#pullrequestreview-1100418585
|
| |
|
|
|
|
|
|
|
| |
This arg expects scan codes and it can be very confusing to find a key
conflict when trying to add a F3 button when there are no F3 keycodes
seemingly in use. CHAR_CARRIAGE_RETURN and SCAN_F3 use the same value,
so no changes in behavior.
|
| |
|
| |
|
|
|
|
| |
SizeOfPartitionEntry must be a multiple of 128 * 2^n.
|
| |
|
| |
|
| |
|
|
|
|
| |
gcc will complain about all these with -Wformat-signedness.
|
|
|
|
|
|
| |
This is a bugfix.
Follow-up for 599fe002a135570406504998dbb7a42dabc963da
|
|
|
|
|
| |
No code change, just some refactoring, so that we can reuse the
measurement logic later elsewhere.
|