Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 9 additions & 1 deletion specs/discoverable_disk_image.md
Original file line number Diff line number Diff line change
Expand Up @@ -14,10 +14,17 @@ extensions, portable services, containers and more, and shall be protected by si
into one. They are designed to be composable and stackable, and provide security by default.

## Image Format

The images use the GPT partition table verbatim, so it will not be redefined here. Each partition contains
a standard Linux filesystem (e.g.: `erofs`), so again this will not be redefined here.
The [DPS](discoverable_partitions_specification.md) defines the GUIDs to use and the format of the
`dm-verity` signature partition's JSON content.
`dm-verity` signature partition's JSON content. The [DPS](discoverable_partitions_specification.md)
allows optional LUKS encryption for additional confidentiality. Note that LUKS encryption by default does not
provide authentication or integrity protection[^1]. A LUKS encrypted partition should be protected by signed
`dm-verity`.
Copy link
Member

Choose a reason for hiding this comment

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

Is there anything actually implementing building such images? And how do they get around the problem of the LUKS header being updated and invalidating the verity hashes?

Copy link
Author

Choose a reason for hiding this comment

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

Is there anything actually implementing building such images?

Not a one-stop shop. I currently create them by a script that makes use of veritysetup + cryptsetup.

I guess the right place to implement that would be systemd-repart. repart currently only supports creating DDIs with verity protection.

And how do they get around the problem of the LUKS header being updated and invalidating the verity hashes?

In this case, LUKS operates on the read-only target provided by dm-verity. Consequently, there is no way for LUKS to update any headers.

Copy link
Member

Choose a reason for hiding this comment

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

Not a one-stop shop. I currently create them by a script that makes use of veritysetup + cryptsetup.

Before being added to a specification there should be at least one common implementation

Copy link
Author

Choose a reason for hiding this comment

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

What would be the right thing to do? Reopen or put it on draft until the repart implementation is done?


[^1]: LUKS2 supports authenticated encryption as an experimental feature.
See [cryptsetup(8) - Authenticated disk encryption](https://man.archlinux.org/man/cryptsetup.8#Authenticated_disk_encryption_(EXPERIMENTAL))

It is recommended to use a sector size of 512 bytes or 4096 for DDIs. Software operating with DDIs should
automatically derive the sector size used for a DDI by looking for the `EFI PART` magic string at offsets 512
Expand All @@ -34,6 +41,7 @@ The MIME type for DDIs is `application/vnd.efi.img`, [as per
IANA](https://www.iana.org/assignments/media-types/application/vnd.efi.img).

## Image Version

If the DDI is versioned, the version format described in the
[Version Format Specification](version_format_specification.md) must be used. The underscore character (`_`)
must be used to separate the version from the name of the image. For example: `foo_1.2.raw` denotes a `foo`
Expand Down