Skip to content

dissect: add support for GPT images with embedded dm-verity signatures #20691

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 9 commits into from
Sep 28, 2021

Conversation

Image for: Conversation
Copy link
Member

The other side of systemd/mkosi#798

poettering changed the title dissect: add support for GPT images with embedded dm-verity signatures Sep 9, 2021
Copy link
Member

bluca commented Sep 9, 2021

I'd much rather avoid this - unless the appropriate sysctl is set, there's no harm in letting the kernel validate too, nothing should happen if the key is not available. If someone has the access rights to place images where they are loaded (sysext, etc) then they most likely can also place their own certs, which in some cases is not good.

uh this comment was inline to a specific check, but it's appearing as a generic comment in the PR? weird?

Copy link
Member Author

/cc @oniko, maybe this is interesting to you?

Copy link
Member Author

uh this comment was inline to a specific check, but it's appearing as a generic comment in the PR? weird?

I think to comment on individual commits of a PR in PR context you now need to click on the Commits tab above first. If you click on commits in the Conversation tab, then it ends up as comment on the commit object outside of PR context.

Pretty stupid if you ask me.

Copy link
Member Author

This should be ready for review now. PTAL!

@bluca i changed the logic now to do signature-based verity setup first via kernel and then fallback to userspace if that didn't work.

Copy link
Member

bluca commented Sep 10, 2021

This should be ready for review now. PTAL!

@bluca i changed the logic now to do signature-based verity setup first via kernel and then fallback to userspace if that didn't work.

Nice, thank you!

The commit message needs updating then:

If one of the certificates found that way works then we'll attempt to
attach the DM device without passing the PKCS7 data to the kernel. If
none works then the behaviour as before is attempted: validation data is
passed to the kernel.
bluca changed the title WIP: dissect: add support for GPT images with embedded dm-verity signatures Sep 10, 2021
Copy link
Member

bluca left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please add some checks in TEST-50-DISSECT? It should be pretty simple to do so, just need to generate the certificates, the rest is there already

poettering added a commit to poettering/mkosi that referenced this pull request Sep 10, 2021
This adds support for creating signed GPT disk images. If Verity=signed
is set this will not only generate and insert Verity data into the
image, but then use the resulting root hash, sign it and include it in
an additional partition. It will also write the resulting PKCS7
signature out into a new .roothash.p7s file.

This scheme is compatible with kernel 5.4's PKCS7 signature logic for
dm-verity: the resulting .p7s file can be passed as-is to the kernel (or
systemd's RootHashSignature= setting).

The partition this embedds contains a simple JSON object containing
three fields. The verity root hash, the PKCS7 data (i.e. the same data
as in the .p7s file, but in base64), and SHA256 fingerprint of the
signing key. This partition is supposed to be read by the image
dissection logic of systemd, to implement signed single-file images.
(The corresponding PR for systemd I am still working on).

This opens up two avenues for image verification:

1. Everything in one file: the single, "unified" GPT disk image contains
   three partitions, for payload data, verity data and verity signature.

2. Split out: root hash and its signature are stored in two "sidecar"
   files.

(Of course I'd personally always go the "unified" way, but given the
RootHashSignature= logic exists already, and it's easy to support, let's
support it.)

This uses the key already used for doing secureboot image signing.
Conceptually this makes a ton of sense: we sign the same stuff here
after all: the contents of the image, supporting two different
entrypoints to the image: one via UEFI booting the image, and once for
attaching directly to an image from a running system. Admittedly, the
"mkosi.secure-boot.key" and "mkosi.secure-boot.certificate" monikers for
this key pair might be a bit suprising though.

Corresponding PR in systemd is:

systemd/systemd#20691
bluca added reviewed/needs-rework 🔨 PR has been reviewed and needs another round of reworks and removed please-review labels Sep 13, 2021
poettering added a commit to poettering/mkosi that referenced this pull request Sep 13, 2021
This adds support for creating signed GPT disk images. If Verity=signed
is set this will not only generate and insert Verity data into the
image, but then use the resulting root hash, sign it and include it in
an additional partition. It will also write the resulting PKCS7
signature out into a new .roothash.p7s file.

This scheme is compatible with kernel 5.4's PKCS7 signature logic for
dm-verity: the resulting .p7s file can be passed as-is to the kernel (or
systemd's RootHashSignature= setting).

The partition this embedds contains a simple JSON object containing
three fields. The verity root hash, the PKCS7 data (i.e. the same data
as in the .p7s file, but in base64), and SHA256 fingerprint of the
signing key. This partition is supposed to be read by the image
dissection logic of systemd, to implement signed single-file images.
(The corresponding PR for systemd I am still working on).

This opens up two avenues for image verification:

1. Everything in one file: the single, "unified" GPT disk image contains
   three partitions, for payload data, verity data and verity signature.

2. Split out: root hash and its signature are stored in two "sidecar"
   files.

(Of course I'd personally always go the "unified" way, but given the
RootHashSignature= logic exists already, and it's easy to support, let's
support it.)

This uses the key already used for doing secureboot image signing.
Conceptually this makes a ton of sense: we sign the same stuff here
after all: the contents of the image, supporting two different
entrypoints to the image: one via UEFI booting the image, and once for
attaching directly to an image from a running system. Admittedly, the
"mkosi.secure-boot.key" and "mkosi.secure-boot.certificate" monikers for
this key pair might be a bit suprising though.

Corresponding PR in systemd is:

systemd/systemd#20691
poettering added a commit to poettering/mkosi that referenced this pull request Sep 13, 2021
This adds support for creating signed GPT disk images. If Verity=signed
is set this will not only generate and insert Verity data into the
image, but then use the resulting root hash, sign it and include it in
an additional partition. It will also write the resulting PKCS7
signature out into a new .roothash.p7s file.

This scheme is compatible with kernel 5.4's PKCS7 signature logic for
dm-verity: the resulting .p7s file can be passed as-is to the kernel (or
systemd's RootHashSignature= setting).

The partition this embedds contains a simple JSON object containing
three fields. The verity root hash, the PKCS7 data (i.e. the same data
as in the .p7s file, but in base64), and SHA256 fingerprint of the
signing key. This partition is supposed to be read by the image
dissection logic of systemd, to implement signed single-file images.
(The corresponding PR for systemd I am still working on).

This opens up two avenues for image verification:

1. Everything in one file: the single, "unified" GPT disk image contains
   three partitions, for payload data, verity data and verity signature.

2. Split out: root hash and its signature are stored in two "sidecar"
   files.

(Of course I'd personally always go the "unified" way, but given the
RootHashSignature= logic exists already, and it's easy to support, let's
support it.)

This uses the key already used for doing secureboot image signing.
Conceptually this makes a ton of sense: we sign the same stuff here
after all: the contents of the image, supporting two different
entrypoints to the image: one via UEFI booting the image, and once for
attaching directly to an image from a running system. Admittedly, the
"mkosi.secure-boot.key" and "mkosi.secure-boot.certificate" monikers for
this key pair might be a bit suprising though.

Corresponding PR in systemd is:

systemd/systemd#20691
This adds support for actually using embedded signature data from
partitions.
Getting certificates for dm-verity roothash signing into the trusted
kernel keychain is a royal PITA (means recompiling or rebooting with
shim), hence let's add a minimal userspace PKCS7 validation as well.

The mechanism is really simple and compatible with the verification the
kernel does. The only difference is that the certificates are searched
in /etc/verity.d/*.crt (and similar dirs in /usr/lib/, …).

We'll first try validation by passing the PKCS#7 data to the kernel, but
if that doesn't work we'll see if one of the certificates found that way
works and then attempt to attach the image without passing the PKCS#7
data to the kernel.

This makes it very easy to have fully validated GPT disk images. For
example, just copy the 'mkosi.secure-boot.crt' file you have in your
mkosi build dir to /etc/verity.d/ and things should just work.
Copy link
Member Author

Addressed all issues and extended the test case. The only interesting change is probably the latter. ptal!

poettering added good-to-merge/waiting-for-ci 👍 PR is good to merge, but CI hasn't passed at time of review. Please merge if you see CI has passed and removed good-to-merge/with-minor-suggestions labels Sep 28, 2021
poettering added please-review and removed good-to-merge/waiting-for-ci 👍 PR is good to merge, but CI hasn't passed at time of review. Please merge if you see CI has passed labels Sep 28, 2021
Copy link
Member

bluca left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

bluca added good-to-merge/waiting-for-ci 👍 PR is good to merge, but CI hasn't passed at time of review. Please merge if you see CI has passed and removed please-review labels Sep 28, 2021
Copy link
Member

bluca commented Sep 28, 2021

I've added the openssl binary to the list of depndencies of the focal tests just now, if it was too late for the run I'll just kick the jobs again later
@mrc0mmand do you need to do a similar change for the centos ones?

Copy link
Member

I've added the openssl binary to the list of depndencies of the focal tests just now, if it was too late for the run I'll just kick the jobs again later @mrc0mmand do you need to do a similar change for the centos ones?

iirc the openssl binary should be in CentOS CI everywhere by default, but let's see if the CIs agree with me (thanks for the heads-up).

poettering merged commit ca3f47e into systemd:main Sep 28, 2021
Copy link
Member

bluca commented Sep 30, 2021

@poettering it seems the test is failing every now and then:

[   69.364854] systemd[458]: run-u6.service: Failed to set up mount namespacing: Required key not available
[   69.373667] systemd[458]: run-u6.service: Failed at step NAMESPACE spawning mount: Required key not available
[   69.376950] systemd[1]: run-u6.service: Failed with result 'exit-code'.

https://autopkgtest.ubuntu.com/results/autopkgtest-focal-upstream-systemd-ci-systemd-ci/focal/amd64/s/systemd-upstream/20210930_141856_7cc4e@/artifacts.tar.gz

ddstreet pushed a commit to ddstreet/systemd that referenced this pull request Oct 5, 2021
The binary is used in a test to generate some test certs, added by:
systemd#20691
keszybz pushed a commit to poettering/mkosi that referenced this pull request Oct 5, 2021
This adds support for creating signed GPT disk images. If Verity=signed
is set this will not only generate and insert Verity data into the
image, but then use the resulting root hash, sign it and include it in
an additional partition. It will also write the resulting PKCS7
signature out into a new .roothash.p7s file.

This scheme is compatible with kernel 5.4's PKCS7 signature logic for
dm-verity: the resulting .p7s file can be passed as-is to the kernel (or
systemd's RootHashSignature= setting).

The partition this embedds contains a simple JSON object containing
three fields. The verity root hash, the PKCS7 data (i.e. the same data
as in the .p7s file, but in base64), and SHA256 fingerprint of the
signing key. This partition is supposed to be read by the image
dissection logic of systemd, to implement signed single-file images.
(The corresponding PR for systemd I am still working on).

This opens up two avenues for image verification:

1. Everything in one file: the single, "unified" GPT disk image contains
   three partitions, for payload data, verity data and verity signature.

2. Split out: root hash and its signature are stored in two "sidecar"
   files.

(Of course I'd personally always go the "unified" way, but given the
RootHashSignature= logic exists already, and it's easy to support, let's
support it.)

This uses the key already used for doing secureboot image signing.
Conceptually this makes a ton of sense: we sign the same stuff here
after all: the contents of the image, supporting two different
entrypoints to the image: one via UEFI booting the image, and once for
attaching directly to an image from a running system. Admittedly, the
"mkosi.secure-boot.key" and "mkosi.secure-boot.certificate" monikers for
this key pair might be a bit suprising though.

Corresponding PR in systemd is:

systemd/systemd#20691
keszybz pushed a commit to poettering/mkosi that referenced this pull request Oct 6, 2021
This adds support for creating signed GPT disk images. If Verity=signed
is set this will not only generate and insert Verity data into the
image, but then use the resulting root hash, sign it and include it in
an additional partition. It will also write the resulting PKCS7
signature out into a new .roothash.p7s file.

This scheme is compatible with kernel 5.4's PKCS7 signature logic for
dm-verity: the resulting .p7s file can be passed as-is to the kernel (or
systemd's RootHashSignature= setting).

The partition this embedds contains a simple JSON object containing
three fields. The verity root hash, the PKCS7 data (i.e. the same data
as in the .p7s file, but in base64), and SHA256 fingerprint of the
signing key. This partition is supposed to be read by the image
dissection logic of systemd, to implement signed single-file images.
(The corresponding PR for systemd I am still working on).

This opens up two avenues for image verification:

1. Everything in one file: the single, "unified" GPT disk image contains
   three partitions, for payload data, verity data and verity signature.

2. Split out: root hash and its signature are stored in two "sidecar"
   files.

(Of course I'd personally always go the "unified" way, but given the
RootHashSignature= logic exists already, and it's easy to support, let's
support it.)

This uses the key already used for doing secureboot image signing.
Conceptually this makes a ton of sense: we sign the same stuff here
after all: the contents of the image, supporting two different
entrypoints to the image: one via UEFI booting the image, and once for
attaching directly to an image from a running system. Admittedly, the
"mkosi.secure-boot.key" and "mkosi.secure-boot.certificate" monikers for
this key pair might be a bit suprising though.

Corresponding PR in systemd is:

systemd/systemd#20691
bluca added a commit to bluca/systemd that referenced this pull request Oct 6, 2021
If the packages are built without libssl simply skip the signature
checks.

Oct 06 21:21:32 H systemd[1]: systemd 249.1249.gcc4df1f787.0 running in system mode (+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS -OPENSSL
...
Oct 06 21:22:21 H systemd[459]: Activation of signed Verity volume worked neither via the kernel nor in userspace, can't activate.

Follow-up for systemd#20691
keszybz pushed a commit that referenced this pull request Oct 7, 2021
If the packages are built without libssl simply skip the signature
checks.

Oct 06 21:21:32 H systemd[1]: systemd 249.1249.gcc4df1f787.0 running in system mode (+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS -OPENSSL
...
Oct 06 21:22:21 H systemd[459]: Activation of signed Verity volume worked neither via the kernel nor in userspace, can't activate.

Follow-up for #20691
ddstreet pushed a commit to ddstreet/systemd that referenced this pull request Nov 6, 2021
Enables additional tests and checks, added by:
systemd#20691
behrmann pushed a commit to uapi-group/specifications that referenced this pull request Oct 18, 2022
dissect: add support for GPT images with embedded dm-verity signatures
keszybz pushed a commit to uapi-group/specifications that referenced this pull request Oct 19, 2022
dissect: add support for GPT images with embedded dm-verity signatures
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dissect documentation good-to-merge/waiting-for-ci 👍 PR is good to merge, but CI hasn't passed at time of review. Please merge if you see CI has passed new-feature resolve
3 participants