-
-
Notifications
You must be signed in to change notification settings - Fork 4k
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
Conversation
uh this comment was inline to a specific check, but it's appearing as a generic comment in the PR? weird? |
/cc @oniko, maybe this is interesting to you? |
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. |
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:
|
There was a problem hiding this 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
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 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 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.
…params Just to make debugging easier.
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.
Addressed all issues and extended the test case. The only interesting change is probably the latter. ptal! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
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 |
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 it seems the test is failing every now and then:
|
The binary is used in a test to generate some test certs, added by: systemd#20691
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 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
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
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
Enables additional tests and checks, added by: systemd#20691
dissect: add support for GPT images with embedded dm-verity signatures
dissect: add support for GPT images with embedded dm-verity signatures
The other side of systemd/mkosi#798