($INBOX_DIR/description missing)
 help / color / mirror / Atom feed
From: "Ulrich Ölmann" <u.oelmann@pengutronix.de>
To: openembedded-devel@lists.openembedded.org
Cc: yocto@pengutronix.de, "Jan Luebbe" <jlu@pengutronix.de>,
	"Rouven Czerwinski" <r.czerwinski@pengutronix.de>,
	"Marco Felsch" <m.felsch@pengutronix.de>,
	"Ulrich Ölmann" <u.oelmann@pengutronix.de>
Subject: [meta-oe][PATCH] Add class for appending dm-verity hash data to block device images
Date: Tue, 23 Apr 2024 12:21:02 +0200	[thread overview]
Message-ID: <20240423102102.1926313-1-u.oelmann@pengutronix.de> (raw)

From: Jan Luebbe <jlu@pengutronix.de>

Add support to generate a dm-verity image and the parameters required to
assemble the corresponding table for the device-mapper driver. The latter will
be stored in the file ${DEPLOY_DIR_IMAGE}/<IMAGE_LINK_NAME>.verity-params.
Note that in the resulting image the hash tree data is appended to the contents
of the original image without an explicit superblock to keep things simple and
compact.

The above mentioned parameter file can be sourced by a shell to finally create
the desired blockdevice via "dmsetup" (found in meta-oe's recipe
"libdevmapper"), e.g.

  . <IMAGE_LINK_NAME>.verity-params
  dmsetup create <dm_dev_name> --readonly --table "0 $VERITY_DATA_SECTORS verity \
      1 <dev> <hash_dev> \
      $VERITY_DATA_BLOCK_SIZE  $VERITY_HASH_BLOCK_SIZE \
      $VERITY_DATA_BLOCKS  $VERITY_DATA_BLOCKS \
      $VERITY_HASH_ALGORITHM  $VERITY_ROOT_HASH  $VERITY_SALT \
      1 ignore_zero_blocks"

As the hash tree data is found at the end of the image, <dev> and <hash_dev>
should be the same blockdevice in the command shown above while <dm_dev_name> is
the name of the to be created dm-verity-device.

The root hash is calculated using a salt to make attacks more difficult. Thus,
please grant each image recipe its own salt which could be generated e.g. via

  dd if=/dev/random bs=1k count=1 | sha256sum

and assign it to the parameter VERITY_SALT.

Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
Signed-off-by: Rouven Czerwinski <r.czerwinski@pengutronix.de>
Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
Signed-off-by: Ulrich Ölmann <u.oelmann@pengutronix.de>
---
 meta-oe/classes/image_types_verity.bbclass | 137 +++++++++++++++++++++
 1 file changed, 137 insertions(+)
 create mode 100644 meta-oe/classes/image_types_verity.bbclass

diff --git a/meta-oe/classes/image_types_verity.bbclass b/meta-oe/classes/image_types_verity.bbclass
new file mode 100644
index 000000000000..b42217c453f2
--- /dev/null
+++ b/meta-oe/classes/image_types_verity.bbclass
@@ -0,0 +1,137 @@
+# SPDX-License-Identifier: MIT
+#
+# Copyright Pengutronix <yocto@pengutronix.de>
+#
+
+# Support generating a dm-verity image and the parameters required to assemble
+# the corresponding table for the device-mapper driver. The latter will be
+# stored in the file ${DEPLOY_DIR_IMAGE}/<IMAGE_LINK_NAME>.verity-params. Note
+# that in the resulting image the hash tree data is appended to the contents of
+# the original image without an explicit superblock to keep things simple and
+# compact.
+#
+# The above mentioned parameter file can be sourced by a shell to finally create
+# the desired blockdevice via "dmsetup" (found in meta-oe's recipe
+# "libdevmapper"), e.g.
+#
+#   . <IMAGE_LINK_NAME>.verity-params
+#   dmsetup create <dm_dev_name> --readonly --table "0 $VERITY_DATA_SECTORS \
+#       verity 1 <dev> <hash_dev> \
+#       $VERITY_DATA_BLOCK_SIZE  $VERITY_HASH_BLOCK_SIZE \
+#       $VERITY_DATA_BLOCKS  $VERITY_DATA_BLOCKS \
+#       $VERITY_HASH_ALGORITHM  $VERITY_ROOT_HASH  $VERITY_SALT \
+#       1 ignore_zero_blocks"
+#
+# As the hash tree data is found at the end of the image, <dev> and <hash_dev>
+# should be the same blockdevice in the command shown above while <dm_dev_name>
+# is the name of the to be created dm-verity-device.
+#
+# The root hash is calculated using a salt to make attacks more difficult. Thus,
+# please grant each image recipe its own salt which could be generated e.g. via
+#
+#   dd if=/dev/random bs=1k count=1 | sha256sum
+#
+# and assign it to the parameter VERITY_SALT.
+
+inherit image-artifact-names
+
+do_image_verity[depends] += "cryptsetup-native:do_populate_sysroot"
+
+CLASS_VERITY_SALT = "4e5f0d9b6ccac5e843598d4e4545046232b48451a399acb2106822b43679b375"
+VERITY_SALT ?= "${CLASS_VERITY_SALT}"
+VERITY_BLOCK_SIZE ?= "4096"
+VERITY_IMAGE_FSTYPE ?= "ext4"
+VERITY_IMAGE_SUFFIX ?= ".verity"
+VERITY_INPUT_IMAGE ?= "${IMGDEPLOYDIR}/${IMAGE_LINK_NAME}.${VERITY_IMAGE_FSTYPE}"
+
+IMAGE_TYPEDEP:verity = "${VERITY_IMAGE_FSTYPE}"
+IMAGE_TYPES_MASKED += "verity"
+
+python __anonymous() {
+    if 'verity' not in d.getVar('IMAGE_FSTYPES'):
+        return
+
+    dep_task = 'do_image_{}'.format(d.getVar('VERITY_IMAGE_FSTYPE').replace('-', '_'))
+    bb.build.addtask('do_image_verity', 'do_image_complete', dep_task, d)
+}
+
+python do_image_verity () {
+    import os
+    import subprocess
+    import shutil
+
+    link = d.getVar('VERITY_INPUT_IMAGE')
+    image = os.path.realpath(link)
+
+    verity_image_suffix = d.getVar('VERITY_IMAGE_SUFFIX')
+    verity = '{}{}'.format(image, verity_image_suffix)
+
+    # For better readability the parameter VERITY_BLOCK_SIZE is specified in
+    # bytes. It must be a multiple of the logical sector size which is 512 bytes
+    # in Linux. Make sure that this is the case as otherwise the resulting
+    # issues would be hard to debug later.
+    block_size = int(d.getVar('VERITY_BLOCK_SIZE'))
+    if block_size % 512 != 0:
+        bb.fatal("VERITY_BLOCK_SIZE must be a multiple of 512!")
+
+    salt = d.getVar('VERITY_SALT')
+    if salt == d.getVar('CLASS_VERITY_SALT'):
+        bb.warn("Please overwrite VERITY_SALT with an image specific one!")
+
+    shutil.copyfile(image, verity)
+
+    data_size_blocks, data_size_rest = divmod(os.stat(verity).st_size, block_size)
+    data_blocks = data_size_blocks + (1 if data_size_rest else 0)
+    data_size = data_blocks * block_size
+
+    bb.debug(1, f"data_size_blocks: {data_size_blocks}, {data_size_rest}")
+    bb.debug(1, f"data_size: {data_size}")
+
+    # Create verity image
+    try:
+        output = subprocess.check_output([
+            'veritysetup', 'format',
+            '--no-superblock',
+            '--salt={}'.format(salt),
+            '--data-blocks={}'.format(data_blocks),
+            '--data-block-size={}'.format(block_size),
+            '--hash-block-size={}'.format(block_size),
+            '--hash-offset={}'.format(data_size),
+            verity, verity,
+            ])
+    except subprocess.CalledProcessError as err:
+        bb.fatal('%s returned with %s (%s)' % (err.cmd, err.returncode, err.output))
+
+    try:
+        with open(image + '.verity-info', 'wb') as f:
+            f.write(output)
+    except Exception as err:
+        bb.fatal('Unexpected error %s' % err)
+
+    # Create verity params
+    params = []
+    for line in output.decode('ASCII').splitlines():
+        if not ':' in line:
+            continue
+        k, v = line.split(':', 1)
+        k = k.strip().upper().replace(' ', '_')
+        v = v.strip()
+        bb.debug(1, f"{k} {v}")
+        params.append('VERITY_{}={}'.format(k, v))
+
+    params.append('VERITY_DATA_SECTORS={}'.format(data_size//512))
+
+    try:
+        with open(image + '.verity-params', 'w') as f:
+            f.write('\n'.join(params))
+    except Exception as err:
+        bb.fatal('Unexpected error %s' % err)
+
+    # Create symlinks
+    for suffix in [ verity_image_suffix, '.verity-info', '.verity-params' ]:
+        try:
+            os.remove(link + suffix)
+        except FileNotFoundError:
+            pass
+        os.symlink(os.path.basename(image) + suffix, link + suffix)
+}
-- 
2.39.2



                 reply	other threads:[~2024-04-23 10:21 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240423102102.1926313-1-u.oelmann@pengutronix.de \
    --to=u.oelmann@pengutronix.de \
    --cc=jlu@pengutronix.de \
    --cc=m.felsch@pengutronix.de \
    --cc=openembedded-devel@lists.openembedded.org \
    --cc=r.czerwinski@pengutronix.de \
    --cc=yocto@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).