GeezerVison

Copy link

Copy Markdown

Member

weilbith, kovacs-andras, and LorbusChris reacted with hooray emoji

poettering force-pushed the gpt-sig branch from 4b68cff to d89cfed Compare September 10, 2021 09:05

poettering force-pushed the gpt-sig branch from d89cfed to 1cdce73 Compare September 10, 2021 19:03

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 reviewed Sep 10, 2021

View reviewed changes

bluca reviewed Sep 10, 2021

View reviewed changes

bluca reviewed Sep 10, 2021

View reviewed changes

bluca reviewed Sep 10, 2021

View reviewed changes

bluca requested changes Sep 10, 2021

View reviewed changes

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

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

poettering force-pushed the gpt-sig branch from 987e21e to bc0d17e Compare September 28, 2021 15:06

poettering force-pushed the gpt-sig branch from bc0d17e to 636c8a1 Compare September 28, 2021 15:07

bluca approved these changes Sep 28, 2021

View reviewed changes

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

[   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'.

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