[meta-security][RFC 0/2] generic dm-verity support + BBB example

[meta-security][RFC 0/2] generic dm-verity support + BBB example

[Bartosz Golaszewski]

From: Bartosz Golaszewski <bgolaszewski@baylibre.com>

I'm terribly sorry for spamming, but I eventually decided to resend it: not
only the tags were messed up but I also added a v2 on top. This time it
should be good.

===

This series attempts to introduce support for dm-verity in meta-security.
It depends on a series[1] I submitted for OE-core that introduces multi-stage
image deployment that's currently pending review (although the general idea
was accepted by Richard). This new way of deploying image artifacts is aimed
at solving a circular dependency problem[2] which turned out to be impossible
to resolve if all artifacts are deployed at once by the do_image_complete task.

The first patch in this series introduces a generic bbclass that allows to
generate and append dm-verity hash data at the end of the partition image.

The second patch adds support for an example verified boot image for Beagle
Bone Black where the root dm-verity hash is stored inside the signed fitImage
in an initramfs which takes care of mouting the protected rootfs.

Patch 2/2 - while made sure to work on BBB - should be generic enough to be
reusable across many platforms.

[1] https://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg135694.html
[2] https://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg134825.html

Bartosz Golaszewski (2):
  classes: provide a class for generating dm-verity meta-data images
  dm-verity: add a working example for BeagleBone Black

 classes/dm-verity-img.bbclass                 | 88 +++++++++++++++++++
 .../images/dm-verity-image-initramfs.bb       | 26 ++++++
 .../initrdscripts/initramfs-dm-verity.bb      | 13 +++
 .../initramfs-dm-verity/init-dm-verity.sh     | 46 ++++++++++
 wic/beaglebone-yocto-verity.wks.in            | 15 ++++
 5 files changed, 188 insertions(+)
 create mode 100644 classes/dm-verity-img.bbclass
 create mode 100644 recipes-core/images/dm-verity-image-initramfs.bb
 create mode 100644 recipes-core/initrdscripts/initramfs-dm-verity.bb
 create mode 100644 recipes-core/initrdscripts/initramfs-dm-verity/init-dm-verity.sh
 create mode 100644 wic/beaglebone-yocto-verity.wks.in

-- 
2.25.0

[meta-security][RFC 1/2] classes: provide a class for generating dm-verity meta-data images

[Bartosz Golaszewski]

From: Bartosz Golaszewski <bgolaszewski@baylibre.com>

This adds a class that allows to generate conversions of ext[234] and
btrfs partitions images with dm-verity hash data appended at the end as
well as a corresponding .env file containing the root hash and data
offset that can be stored in a secure location (e.g. signed fitImage)
or signed and verified at run-time on its own.

The class depends on two variables:
  DM_VERITY_IMAGE:      defines the name of the main image (normally the
                        one that is used with the bitbake command to
                        build the main image)
  DM_VERITY_IMAGE_TYPE: defines exactly one type for which to generate
                        the protected image.

Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
 classes/dm-verity-img.bbclass | 88 +++++++++++++++++++++++++++++++++++
 1 file changed, 88 insertions(+)
 create mode 100644 classes/dm-verity-img.bbclass

diff --git a/classes/dm-verity-img.bbclass b/classes/dm-verity-img.bbclass
new file mode 100644
index 0000000..1c0e29b
--- /dev/null
+++ b/classes/dm-verity-img.bbclass
@@ -0,0 +1,88 @@
+# SPDX-License-Identifier: MIT
+#
+# Copyright (C) 2020 BayLibre SAS
+# Author: Bartosz Golaszewski <bgolaszewski@baylibre.com>
+#
+# This bbclass allows creating of dm-verity protected partition images. It
+# generates a device image file with dm-verity hash data appended at the end
+# plus the corresponding .env file containing additional information needed
+# to mount the image such as the root hash in the form of ell variables. To
+# assure data integrity, the root hash must be stored in a trusted location
+# or cryptographically signed and verified.
+#
+# Usage:
+#     DM_VERITY_IMAGE = "core-image-full-cmdline" # or other image
+#     DM_VERITY_IMAGE_TYPE = "ext4" # or ext2, ext3 & btrfs
+#     IMAGE_CLASSES += "dm-verity-img"
+#
+# The resulting image can then be used to implement the device mapper block
+# integrity checking on the target device.
+
+# Process the output from veritysetup and generate the corresponding .env
+# file. The output from veritysetup is not very machine-friendly so we need to
+# convert it to some better format. Let's drop the first line (doesn't contain
+# any useful info) and feed the rest to a script.
+process_verity() {
+    local ENV="$OUTPUT.env"
+
+    # Each line contains a key and a value string delimited by ':'. Read the
+    # two parts into separate variables and process them separately. For the
+    # key part: convert the names to upper case and replace spaces with
+    # underscores to create correct shell variable names. For the value part:
+    # just trim all white-spaces.
+    IFS=":"
+    while read KEY VAL; do
+        echo -ne "$KEY" | tr '[:lower:]' '[:upper:]' | sed 's/ /_/g' >> $ENV
+        echo -ne "=" >> $ENV
+        echo "$VAL" | tr -d " \t" >> $ENV
+    done
+
+    # Add partition size
+    echo "DATA_SIZE=$SIZE" >> $ENV
+
+    ln -sf $ENV ${IMAGE_BASENAME}-${MACHINE}.$TYPE.verity.env
+}
+
+verity_setup() {
+    local TYPE=$1
+    local INPUT=${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.$TYPE
+    local SIZE=$(stat --printf="%s" $INPUT)
+    local OUTPUT=$INPUT.verity
+
+    cp -a $INPUT $OUTPUT
+
+    # Let's drop the first line of output (doesn't contain any useful info)
+    # and feed the rest to another function.
+    veritysetup --data-block-size=1024 --hash-offset=$SIZE format $OUTPUT $OUTPUT | tail -n +2 | process_verity
+}
+
+VERITY_TYPES = "ext2.verity ext3.verity ext4.verity btrfs.verity"
+IMAGE_TYPES += "${VERITY_TYPES}"
+CONVERSIONTYPES += "verity"
+CONVERSION_CMD_verity = "verity_setup ${type}"
+CONVERSION_DEPENDS_verity = "cryptsetup-native"
+
+python __anonymous() {
+    verity_image = d.getVar('DM_VERITY_IMAGE')
+    verity_type = d.getVar('DM_VERITY_IMAGE_TYPE')
+    image_fstypes = d.getVar('IMAGE_FSTYPES')
+    pn = d.getVar('PN')
+
+    if verity_image != pn:
+        return # This doesn't concern this image
+
+    if not verity_image or not verity_type:
+        bb.warn('dm-verity-img class inherited but not used')
+        return
+
+    if len(verity_type.split()) is not 1:
+        bb.fatal('DM_VERITY_IMAGE_TYPE must contain exactly one type')
+
+    d.appendVar('IMAGE_FSTYPES', ' %s.verity' % verity_type)
+
+    # If we're using wic: we'll have to use partition images and not the rootfs
+    # source plugin so add the appropriate dependency.
+    if 'wic' in image_fstypes:
+        dep = ' %s:do_image_%s' % (pn, verity_type)
+        d.appendVarFlag('do_image_wic', 'depends', dep)
+}
-- 
2.25.0

[meta-security][RFC 2/2] dm-verity: add a working example for BeagleBone Black

[Bartosz Golaszewski]

From: Bartosz Golaszewski <bgolaszewski@baylibre.com>

This adds various bits and pieces to enable generating a working example
of a full chain of trust up to dm-verity-protected rootfs level on Beagle
Bone Black.

The new initramfs is quite generic and should work for other SoCs as well
when using fitImage.

The following config can be used with current master poky,
meta-openembedded & meta-security to generate a BBB image using verified
boot and dm-verity.

  UBOOT_SIGN_KEYDIR = "/tmp/test-keys/"
  UBOOT_SIGN_KEYNAME = "dev"
  UBOOT_SIGN_ENABLE = "1"
  UBOOT_MKIMAGE_DTCOPTS = "-I dts -O dtb -p 2000"
  UBOOT_MACHINE_beaglebone-yocto = "am335x_boneblack_vboot_config"

  IMAGE_CLASSES += "dm-verity-img"
  IMAGE_FSTYPES += "wic.xz ext4"

  DM_VERITY_IMAGE = "core-image-full-cmdline"
  DM_VERITY_IMAGE_TYPE = "ext4"

  KERNEL_CLASSES += "kernel-fitimage"
  KERNEL_IMAGETYPE_beaglebone-yocto = "fitImage"

  IMAGE_INSTALL_remove = " kernel-image-zimage"
  IMAGE_BOOT_FILES_remove = " zImage"
  IMAGE_BOOT_FILES_append = " fitImage-${INITRAMFS_IMAGE}-${MACHINE}-${MACHINE};fitImage"

  # Using systemd is not strictly needed but deals nicely with read-only
  # filesystem by default.
  DISTRO_FEATURES_append = " systemd"
  DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit"
  VIRTUAL-RUNTIME_init_manager = "systemd"
  VIRTUAL-RUNTIME_initscripts = "systemd-compat-units"

  INITRAMFS_IMAGE = "dm-verity-image-initramfs"
  INITRAMFS_FSTYPES = "cpio.gz"
  INITRAMFS_IMAGE_BUNDLE = "1"

  WKS_FILE = "beaglebone-yocto-verity.wks.in"

  KERNEL_FEATURES_append = " features/device-mapper/dm-verity.scc"

Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
 .../images/dm-verity-image-initramfs.bb       | 26 +++++++++++
 .../initrdscripts/initramfs-dm-verity.bb      | 13 ++++++
 .../initramfs-dm-verity/init-dm-verity.sh     | 46 +++++++++++++++++++
 wic/beaglebone-yocto-verity.wks.in            | 15 ++++++
 4 files changed, 100 insertions(+)
 create mode 100644 recipes-core/images/dm-verity-image-initramfs.bb
 create mode 100644 recipes-core/initrdscripts/initramfs-dm-verity.bb
 create mode 100644 recipes-core/initrdscripts/initramfs-dm-verity/init-dm-verity.sh
 create mode 100644 wic/beaglebone-yocto-verity.wks.in

diff --git a/recipes-core/images/dm-verity-image-initramfs.bb b/recipes-core/images/dm-verity-image-initramfs.bb
new file mode 100644
index 0000000..f9ea376
--- /dev/null
+++ b/recipes-core/images/dm-verity-image-initramfs.bb
@@ -0,0 +1,26 @@
+DESCRIPTION = "Simple initramfs image for mounting the rootfs over the verity device mapper."
+
+# We want a clean, minimal image.
+IMAGE_FEATURES = ""
+
+PACKAGE_INSTALL = " \
+    initramfs-dm-verity \
+    base-files \
+    busybox \
+    util-linux-mount \
+    udev \
+    cryptsetup \
+    lvm2-udevrules \
+"
+
+# Can we somehow inspect reverse dependencies to avoid these variables?
+do_rootfs[depends] += "${DM_VERITY_IMAGE}:do_image_${DM_VERITY_IMAGE_TYPE}"
+
+IMAGE_FSTYPES = "${INITRAMFS_FSTYPES}"
+
+inherit core-image
+
+deploy_verity_hash() {
+    install -D -m 0644 ${DEPLOY_DIR_IMAGE}/${DM_VERITY_IMAGE}-${MACHINE}.${DM_VERITY_IMAGE_TYPE}.verity.env ${IMAGE_ROOTFS}/${datadir}/dm-verity.env
+}
+ROOTFS_POSTPROCESS_COMMAND += "deploy_verity_hash;"
diff --git a/recipes-core/initrdscripts/initramfs-dm-verity.bb b/recipes-core/initrdscripts/initramfs-dm-verity.bb
new file mode 100644
index 0000000..b614956
--- /dev/null
+++ b/recipes-core/initrdscripts/initramfs-dm-verity.bb
@@ -0,0 +1,13 @@
+SUMMARY = "Simple init script that uses devmapper to mount the rootfs in read-only mode protected by dm-verity"
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = "file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
+
+SRC_URI = "file://init-dm-verity.sh"
+
+do_install() {
+    install -m 0755 ${WORKDIR}/init-dm-verity.sh ${D}/init
+    install -d ${D}/dev
+    mknod -m 622 ${D}/dev/console c 5 1
+}
+
+FILES_${PN} = "/init /dev/console"
diff --git a/recipes-core/initrdscripts/initramfs-dm-verity/init-dm-verity.sh b/recipes-core/initrdscripts/initramfs-dm-verity/init-dm-verity.sh
new file mode 100644
index 0000000..307d2c7
--- /dev/null
+++ b/recipes-core/initrdscripts/initramfs-dm-verity/init-dm-verity.sh
@@ -0,0 +1,46 @@
+#!/bin/sh
+
+PATH=/sbin:/bin:/usr/sbin:/usr/bin
+RDEV=""
+ROOT_DIR="/new_root"
+
+mkdir -p /proc
+mkdir -p /sys
+mkdir -p /run
+mkdir -p /tmp
+mount -t proc proc /proc
+mount -t sysfs sysfs /sys
+mount -t devtmpfs none /dev
+
+udevd --daemon
+udevadm trigger --type=subsystems --action=add
+udevadm trigger --type=devices --action=add
+udevadm settle --timeout=10
+
+for PARAM in $(cat /proc/cmdline); do
+	case $PARAM in
+		root=*)
+			RDEV=${PARAM#root=}
+			;;
+	esac
+done
+
+if ! [ -b $RDEV ]; then
+	echo "Missing root command line argument!"
+	exit 1
+fi
+
+case $RDEV in
+	UUID=*)
+		RDEV=$(realpath /dev/disk/by-uuid/${RDEV#UUID=})
+		;;
+esac
+
+. /usr/share/dm-verity.env
+
+echo "Mounting $RDEV over dm-verity as the root filesystem"
+
+veritysetup --data-block-size=1024 --hash-offset=$DATA_SIZE create rootfs $RDEV $RDEV $ROOT_HASH
+mkdir -p $ROOT_DIR
+mount -o ro /dev/mapper/rootfs $ROOT_DIR
+exec switch_root $ROOT_DIR /sbin/init
diff --git a/wic/beaglebone-yocto-verity.wks.in b/wic/beaglebone-yocto-verity.wks.in
new file mode 100644
index 0000000..cd1702e
--- /dev/null
+++ b/wic/beaglebone-yocto-verity.wks.in
@@ -0,0 +1,15 @@
+# SPDX-License-Identifier: MIT
+#
+# Copyright (C) 2020 BayLibre SAS
+# Author: Bartosz Golaszewski <bgolaszewski@baylibre.com>
+#
+# A dm-verity variant of the regular wks for beaglebone black. We need to fetch
+# the partition images from the DEPLOY_DIR_IMAGE as the rootfs source plugin will
+# not recreate the exact block device corresponding with the hash tree. We must
+# not alter the label or any other setting on the image.
+#
+# This .wks only works with the dm-verity-img class.
+
+part /boot --source bootimg-partition --ondisk mmcblk0 --fstype=vfat --label boot --active --align 4 --size 16 --sourceparams="loader=u-boot" --use-uuid
+part / --source rawcopy --ondisk mmcblk0 --sourceparams="file=${DEPLOY_DIR_IMAGE}/${DM_VERITY_IMAGE}-${MACHINE}.${DM_VERITY_IMAGE_TYPE}.verity"
+bootloader --append="console=ttyS0,115200"
-- 
2.25.0

Re: [oe] [meta-security][RFC 2/2] dm-verity: add a working example for BeagleBone Black

[Ayoub Zaki]

Hi,


On 10.04.20 14:41, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> This adds various bits and pieces to enable generating a working example
> of a full chain of trust up to dm-verity-protected rootfs level on Beagle
> Bone Black.
>
> The new initramfs is quite generic and should work for other SoCs as well
> when using fitImage.
>
> The following config can be used with current master poky,
> meta-openembedded & meta-security to generate a BBB image using verified
> boot and dm-verity.
>
>    UBOOT_SIGN_KEYDIR = "/tmp/test-keys/"
>    UBOOT_SIGN_KEYNAME = "dev"
>    UBOOT_SIGN_ENABLE = "1"
>    UBOOT_MKIMAGE_DTCOPTS = "-I dts -O dtb -p 2000"
>    UBOOT_MACHINE_beaglebone-yocto = "am335x_boneblack_vboot_config"
>
>    IMAGE_CLASSES += "dm-verity-img"
>    IMAGE_FSTYPES += "wic.xz ext4"
>
>    DM_VERITY_IMAGE = "core-image-full-cmdline"
>    DM_VERITY_IMAGE_TYPE = "ext4"
>
>    KERNEL_CLASSES += "kernel-fitimage"
>    KERNEL_IMAGETYPE_beaglebone-yocto = "fitImage"
>
>    IMAGE_INSTALL_remove = " kernel-image-zimage"
>    IMAGE_BOOT_FILES_remove = " zImage"
>    IMAGE_BOOT_FILES_append = " fitImage-${INITRAMFS_IMAGE}-${MACHINE}-${MACHINE};fitImage"
>
>    # Using systemd is not strictly needed but deals nicely with read-only
>    # filesystem by default.
>    DISTRO_FEATURES_append = " systemd"
>    DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit"
>    VIRTUAL-RUNTIME_init_manager = "systemd"
>    VIRTUAL-RUNTIME_initscripts = "systemd-compat-units"
>
>    INITRAMFS_IMAGE = "dm-verity-image-initramfs"
>    INITRAMFS_FSTYPES = "cpio.gz"
>    INITRAMFS_IMAGE_BUNDLE = "1"
>
>    WKS_FILE = "beaglebone-yocto-verity.wks.in"
>
>    KERNEL_FEATURES_append = " features/device-mapper/dm-verity.scc"
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
>   .../images/dm-verity-image-initramfs.bb       | 26 +++++++++++
>   .../initrdscripts/initramfs-dm-verity.bb      | 13 ++++++
>   .../initramfs-dm-verity/init-dm-verity.sh     | 46 +++++++++++++++++++
>   wic/beaglebone-yocto-verity.wks.in            | 15 ++++++
>   4 files changed, 100 insertions(+)
>   create mode 100644 recipes-core/images/dm-verity-image-initramfs.bb
>   create mode 100644 recipes-core/initrdscripts/initramfs-dm-verity.bb
>   create mode 100644 recipes-core/initrdscripts/initramfs-dm-verity/init-dm-verity.sh
>   create mode 100644 wic/beaglebone-yocto-verity.wks.in
>
> diff --git a/recipes-core/images/dm-verity-image-initramfs.bb b/recipes-core/images/dm-verity-image-initramfs.bb
> new file mode 100644
> index 0000000..f9ea376
> --- /dev/null
> +++ b/recipes-core/images/dm-verity-image-initramfs.bb
> @@ -0,0 +1,26 @@
> +DESCRIPTION = "Simple initramfs image for mounting the rootfs over the verity device mapper."
> +
> +# We want a clean, minimal image.
> +IMAGE_FEATURES = ""
> +
> +PACKAGE_INSTALL = " \
> +    initramfs-dm-verity \
> +    base-files \
> +    busybox \
> +    util-linux-mount \
> +    udev \
> +    cryptsetup \
> +    lvm2-udevrules \
> +"
> +
> +# Can we somehow inspect reverse dependencies to avoid these variables?
> +do_rootfs[depends] += "${DM_VERITY_IMAGE}:do_image_${DM_VERITY_IMAGE_TYPE}"
> +
> +IMAGE_FSTYPES = "${INITRAMFS_FSTYPES}"
> +
> +inherit core-image
> +
> +deploy_verity_hash() {
> +    install -D -m 0644 ${DEPLOY_DIR_IMAGE}/${DM_VERITY_IMAGE}-${MACHINE}.${DM_VERITY_IMAGE_TYPE}.verity.env ${IMAGE_ROOTFS}/${datadir}/dm-verity.env
> +}
> +ROOTFS_POSTPROCESS_COMMAND += "deploy_verity_hash;"
> diff --git a/recipes-core/initrdscripts/initramfs-dm-verity.bb b/recipes-core/initrdscripts/initramfs-dm-verity.bb
> new file mode 100644
> index 0000000..b614956
> --- /dev/null
> +++ b/recipes-core/initrdscripts/initramfs-dm-verity.bb
> @@ -0,0 +1,13 @@
> +SUMMARY = "Simple init script that uses devmapper to mount the rootfs in read-only mode protected by dm-verity"
> +LICENSE = "MIT"
> +LIC_FILES_CHKSUM = "file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
> +
> +SRC_URI = "file://init-dm-verity.sh"
> +
> +do_install() {
> +    install -m 0755 ${WORKDIR}/init-dm-verity.sh ${D}/init
> +    install -d ${D}/dev
> +    mknod -m 622 ${D}/dev/console c 5 1
> +}
> +
> +FILES_${PN} = "/init /dev/console"
> diff --git a/recipes-core/initrdscripts/initramfs-dm-verity/init-dm-verity.sh b/recipes-core/initrdscripts/initramfs-dm-verity/init-dm-verity.sh
> new file mode 100644
> index 0000000..307d2c7
> --- /dev/null
> +++ b/recipes-core/initrdscripts/initramfs-dm-verity/init-dm-verity.sh
> @@ -0,0 +1,46 @@
> +#!/bin/sh
> +
> +PATH=/sbin:/bin:/usr/sbin:/usr/bin
> +RDEV=""
> +ROOT_DIR="/new_root"
> +
> +mkdir -p /proc
> +mkdir -p /sys
> +mkdir -p /run
> +mkdir -p /tmp
> +mount -t proc proc /proc
> +mount -t sysfs sysfs /sys
> +mount -t devtmpfs none /dev
> +
> +udevd --daemon
> +udevadm trigger --type=subsystems --action=add
> +udevadm trigger --type=devices --action=add
> +udevadm settle --timeout=10
> +
> +for PARAM in $(cat /proc/cmdline); do
> +	case $PARAM in
> +		root=*)
> +			RDEV=${PARAM#root=}
> +			;;
> +	esac
> +done
> +
> +if ! [ -b $RDEV ]; then
> +	echo "Missing root command line argument!"
> +	exit 1
> +fi
> +
> +case $RDEV in
> +	UUID=*)
> +		RDEV=$(realpath /dev/disk/by-uuid/${RDEV#UUID=})
> +		;;
> +esac
> +
> +. /usr/share/dm-verity.env
> +
> +echo "Mounting $RDEV over dm-verity as the root filesystem"
> +
> +veritysetup --data-block-size=1024 --hash-offset=$DATA_SIZE create rootfs $RDEV $RDEV $ROOT_HASH
> +mkdir -p $ROOT_DIR
> +mount -o ro /dev/mapper/rootfs $ROOT_DIR
> +exec switch_root $ROOT_DIR /sbin/init
> diff --git a/wic/beaglebone-yocto-verity.wks.in b/wic/beaglebone-yocto-verity.wks.in
> new file mode 100644
> index 0000000..cd1702e
> --- /dev/null
> +++ b/wic/beaglebone-yocto-verity.wks.in
> @@ -0,0 +1,15 @@
> +# SPDX-License-Identifier: MIT
> +#
> +# Copyright (C) 2020 BayLibre SAS
> +# Author: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> +#
> +# A dm-verity variant of the regular wks for beaglebone black. We need to fetch
> +# the partition images from the DEPLOY_DIR_IMAGE as the rootfs source plugin will
> +# not recreate the exact block device corresponding with the hash tree. We must
> +# not alter the label or any other setting on the image.
> +#
> +# This .wks only works with the dm-verity-img class.
> +
> +part /boot --source bootimg-partition --ondisk mmcblk0 --fstype=vfat --label boot --active --align 4 --size 16 --sourceparams="loader=u-boot" --use-uuid
> +part / --source rawcopy --ondisk mmcblk0 --sourceparams="file=${DEPLOY_DIR_IMAGE}/${DM_VERITY_IMAGE}-${MACHINE}.${DM_VERITY_IMAGE_TYPE}.verity"
> +bootloader --append="console=ttyS0,115200"


Not sure if it's a working example...so where does the fitImage goes ?

How did you solve the circular dependency ?


Mit freundlichen Grüßen / Kind regards

-- 
Ayoub Zaki
Embedded Systems Consultant

Vaihinger Straße 2/1
D-71634 Ludwigsburg

Mobile   : +4917662901545
Email    : ayoub.zaki@embexus.com
Homepage : https://embexus.com
VAT No.  : DE313902634

Re: [oe] [meta-security][RFC 1/2] classes: provide a class for generating dm-verity meta-data images

[Ayoub Zaki]

Hi,


On 10.04.20 14:41, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> This adds a class that allows to generate conversions of ext[234] and
> btrfs partitions images with dm-verity hash data appended at the end as
> well as a corresponding .env file containing the root hash and data
> offset that can be stored in a secure location (e.g. signed fitImage)
> or signed and verified at run-time on its own.
>
> The class depends on two variables:
>    DM_VERITY_IMAGE:      defines the name of the main image (normally the
>                          one that is used with the bitbake command to
>                          build the main image)
>    DM_VERITY_IMAGE_TYPE: defines exactly one type for which to generate
>                          the protected image.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
>   classes/dm-verity-img.bbclass | 88 +++++++++++++++++++++++++++++++++++
>   1 file changed, 88 insertions(+)
>   create mode 100644 classes/dm-verity-img.bbclass
>
> diff --git a/classes/dm-verity-img.bbclass b/classes/dm-verity-img.bbclass
> new file mode 100644
> index 0000000..1c0e29b
> --- /dev/null
> +++ b/classes/dm-verity-img.bbclass
> @@ -0,0 +1,88 @@
> +# SPDX-License-Identifier: MIT
> +#
> +# Copyright (C) 2020 BayLibre SAS
> +# Author: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> +#
> +# This bbclass allows creating of dm-verity protected partition images. It
> +# generates a device image file with dm-verity hash data appended at the end
> +# plus the corresponding .env file containing additional information needed
> +# to mount the image such as the root hash in the form of ell variables. To
> +# assure data integrity, the root hash must be stored in a trusted location
> +# or cryptographically signed and verified.
> +#
> +# Usage:
> +#     DM_VERITY_IMAGE = "core-image-full-cmdline" # or other image
> +#     DM_VERITY_IMAGE_TYPE = "ext4" # or ext2, ext3 & btrfs
> +#     IMAGE_CLASSES += "dm-verity-img"
> +#
> +# The resulting image can then be used to implement the device mapper block
> +# integrity checking on the target device.
> +
> +# Process the output from veritysetup and generate the corresponding .env
> +# file. The output from veritysetup is not very machine-friendly so we need to
> +# convert it to some better format. Let's drop the first line (doesn't contain
> +# any useful info) and feed the rest to a script.
> +process_verity() {
> +    local ENV="$OUTPUT.env"
> +
> +    # Each line contains a key and a value string delimited by ':'. Read the
> +    # two parts into separate variables and process them separately. For the
> +    # key part: convert the names to upper case and replace spaces with
> +    # underscores to create correct shell variable names. For the value part:
> +    # just trim all white-spaces.
> +    IFS=":"
> +    while read KEY VAL; do
> +        echo -ne "$KEY" | tr '[:lower:]' '[:upper:]' | sed 's/ /_/g' >> $ENV
> +        echo -ne "=" >> $ENV
> +        echo "$VAL" | tr -d " \t" >> $ENV
> +    done
> +
> +    # Add partition size
> +    echo "DATA_SIZE=$SIZE" >> $ENV
> +
> +    ln -sf $ENV ${IMAGE_BASENAME}-${MACHINE}.$TYPE.verity.env
> +}
> +
> +verity_setup() {
> +    local TYPE=$1
> +    local INPUT=${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.$TYPE
> +    local SIZE=$(stat --printf="%s" $INPUT)
> +    local OUTPUT=$INPUT.verity
> +
> +    cp -a $INPUT $OUTPUT
> +
> +    # Let's drop the first line of output (doesn't contain any useful info)
> +    # and feed the rest to another function.
> +    veritysetup --data-block-size=1024 --hash-offset=$SIZE format $OUTPUT $OUTPUT | tail -n +2 | process_verity
> +}
> +
> +VERITY_TYPES = "ext2.verity ext3.verity ext4.verity btrfs.verity"
> +IMAGE_TYPES += "${VERITY_TYPES}"
> +CONVERSIONTYPES += "verity"
> +CONVERSION_CMD_verity = "verity_setup ${type}"
> +CONVERSION_DEPENDS_verity = "cryptsetup-native"
> +
> +python __anonymous() {
> +    verity_image = d.getVar('DM_VERITY_IMAGE')
> +    verity_type = d.getVar('DM_VERITY_IMAGE_TYPE')
> +    image_fstypes = d.getVar('IMAGE_FSTYPES')
> +    pn = d.getVar('PN')
> +
> +    if verity_image != pn:
> +        return # This doesn't concern this image
> +
> +    if not verity_image or not verity_type:
> +        bb.warn('dm-verity-img class inherited but not used')
> +        return
> +
> +    if len(verity_type.split()) is not 1:
> +        bb.fatal('DM_VERITY_IMAGE_TYPE must contain exactly one type')
> +
> +    d.appendVar('IMAGE_FSTYPES', ' %s.verity' % verity_type)
> +
> +    # If we're using wic: we'll have to use partition images and not the rootfs
> +    # source plugin so add the appropriate dependency.
> +    if 'wic' in image_fstypes:
> +        dep = ' %s:do_image_%s' % (pn, verity_type)
> +        d.appendVarFlag('do_image_wic', 'depends', dep)
> +}
>

basically this class generate a dm-verity hash that needs to be injected 
inside the initramfs...it's a bit hacky.

wouldn't be signing the hash, include the verifiication public key in 
initramfs more portable ?


Mit freundlichen Grüßen / Kind regards

-- 
Ayoub Zaki
Embedded Systems Consultant

Vaihinger Straße 2/1
D-71634 Ludwigsburg

Mobile   : +4917662901545
Email    : ayoub.zaki@embexus.com
Homepage : https://embexus.com
VAT No.  : DE313902634

Re: [oe] [meta-security][RFC 1/2] classes: provide a class for generating dm-verity meta-data images

[Bartosz Golaszewski]

pon., 13 kwi 2020 o 12:58 Ayoub Zaki <ayoub.zaki@embexus.com> napisał(a):
>
>
> basically this class generate a dm-verity hash that needs to be injected
> inside the initramfs...it's a bit hacky.
>
> wouldn't be signing the hash, include the verifiication public key in
> initramfs more portable ?
>

Sorry, but I don't see how this is a better solution. You then have to
store two things somewhere: the hash and its signature. If the
fitImage is already signed - there's no reason to have a second
signature for the hash: it already comes from a trusted source.

This would also inflate the size of the initramfs - not only would it
need to include the cryptsetup tools but also additional tools for
signature verification.

Bart

Re: [oe] [meta-security][RFC 2/2] dm-verity: add a working example for BeagleBone Black

[Bartosz Golaszewski]

pon., 13 kwi 2020 o 12:53 Ayoub Zaki <ayoub.zaki@embexus.com> napisał(a):
>
> Hi,
>
>
> On 10.04.20 14:41, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> >
> > This adds various bits and pieces to enable generating a working example
> > of a full chain of trust up to dm-verity-protected rootfs level on Beagle
> > Bone Black.
> >
> > The new initramfs is quite generic and should work for other SoCs as well
> > when using fitImage.
> >
> > The following config can be used with current master poky,
> > meta-openembedded & meta-security to generate a BBB image using verified
> > boot and dm-verity.
> >
> >    UBOOT_SIGN_KEYDIR = "/tmp/test-keys/"
> >    UBOOT_SIGN_KEYNAME = "dev"
> >    UBOOT_SIGN_ENABLE = "1"
> >    UBOOT_MKIMAGE_DTCOPTS = "-I dts -O dtb -p 2000"
> >    UBOOT_MACHINE_beaglebone-yocto = "am335x_boneblack_vboot_config"
> >
> >    IMAGE_CLASSES += "dm-verity-img"
> >    IMAGE_FSTYPES += "wic.xz ext4"
> >
> >    DM_VERITY_IMAGE = "core-image-full-cmdline"
> >    DM_VERITY_IMAGE_TYPE = "ext4"
> >
> >    KERNEL_CLASSES += "kernel-fitimage"
> >    KERNEL_IMAGETYPE_beaglebone-yocto = "fitImage"
> >
> >    IMAGE_INSTALL_remove = " kernel-image-zimage"
> >    IMAGE_BOOT_FILES_remove = " zImage"
> >    IMAGE_BOOT_FILES_append = " fitImage-${INITRAMFS_IMAGE}-${MACHINE}-${MACHINE};fitImage"
> >
> >    # Using systemd is not strictly needed but deals nicely with read-only
> >    # filesystem by default.
> >    DISTRO_FEATURES_append = " systemd"
> >    DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit"
> >    VIRTUAL-RUNTIME_init_manager = "systemd"
> >    VIRTUAL-RUNTIME_initscripts = "systemd-compat-units"
> >
> >    INITRAMFS_IMAGE = "dm-verity-image-initramfs"
> >    INITRAMFS_FSTYPES = "cpio.gz"
> >    INITRAMFS_IMAGE_BUNDLE = "1"
> >
> >    WKS_FILE = "beaglebone-yocto-verity.wks.in"
> >
> >    KERNEL_FEATURES_append = " features/device-mapper/dm-verity.scc"
> >
> > Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
>
> Not sure if it's a working example...so where does the fitImage goes ?
>
> How did you solve the circular dependency ?
>
>

Please refer to the cover letter - it points to a patch series for
OE-core where I fixed the problem in image and sstate bbclasses.

Bart

Re: [oe] [meta-security][RFC 1/2] classes: provide a class for generating dm-verity meta-data images

[Ayoub Zaki]

[-- Attachment #1: Type: text/plain, Size: 1630 bytes --]

Hi,

On 14.04.20 11:05, Bartosz Golaszewski wrote:
> pon., 13 kwi 2020 o 12:58 Ayoub Zaki <ayoub.zaki@embexus.com> napisał(a):
>>
>> basically this class generate a dm-verity hash that needs to be injected
>> inside the initramfs...it's a bit hacky.
>>
>> wouldn't be signing the hash, include the verifiication public key in
>> initramfs more portable ?
>>
> Sorry, but I don't see how this is a better solution. You then have to
> store two things somewhere: the hash and its signature. If the
> fitImage is already signed - there's no reason to have a second
> signature for the hash: it already comes from a trusted source.
>
> This would also inflate the size of the initramfs - not only would it
> need to include the cryptsetup tools but also additional tools for
> signature verification.


The hash + signature doesn't need to be stored in initramfs in this case 
but appended to the rootfs image.

yes you would need in this case a signature verification tool inside 
your initramfs and the corresponding public key.

It is clearly much better than to poke around with circular dependencies.


 From another point the veritysetup is not quite correct:

veritysetup --data-block-size=1024 --hash-offset=$SIZE format $OUTPUT 
$OUTPUT


If the size of your image is not 1K multiple then you are excluding the 
last block!

Mit freundlichen Grüßen / Kind regards

-- 
Ayoub Zaki
Embedded Systems Consultant

Vaihinger Straße 2/1
D-71634 Ludwigsburg


Mobile   : +4917662901545
Email    : ayoub.zaki@embexus.com
Homepage : https://embexus.com
VAT No.  : DE313902634


[-- Attachment #2: Type: text/html, Size: 3694 bytes --]

Re: [oe] [meta-security][RFC 1/2] classes: provide a class for generating dm-verity meta-data images

[Bartosz Golaszewski]

wt., 14 kwi 2020 o 11:17 Ayoub Zaki <ayoub.zaki@embexus.com> napisał(a):
>
> Hi,
>
> On 14.04.20 11:05, Bartosz Golaszewski wrote:
>
> pon., 13 kwi 2020 o 12:58 Ayoub Zaki <ayoub.zaki@embexus.com> napisał(a):
>
> basically this class generate a dm-verity hash that needs to be injected
> inside the initramfs...it's a bit hacky.
>
> wouldn't be signing the hash, include the verifiication public key in
> initramfs more portable ?
>
> Sorry, but I don't see how this is a better solution. You then have to
> store two things somewhere: the hash and its signature. If the
> fitImage is already signed - there's no reason to have a second
> signature for the hash: it already comes from a trusted source.
>
> This would also inflate the size of the initramfs - not only would it
> need to include the cryptsetup tools but also additional tools for
> signature verification.
>
>
> The hash + signature doesn't need to be stored in initramfs in this case but appended to the rootfs image.
>
> yes you would need in this case a signature verification tool inside your initramfs and the corresponding public key.
>

But how is this better? I know this is how Android does dm-verity, but
it's not any simpler - I'd argue the actual implementation is more
complicated.

> It is clearly much better than to poke around with circular dependencies.
>

No it's not clearly better. Circular dependencies result from bad
design and should be fixed. I proposed simple changes that fix them in
OE-core.

>
> From another point the veritysetup is not quite correct:
>
> veritysetup --data-block-size=1024 --hash-offset=$SIZE format $OUTPUT $OUTPUT
>
>
> If the size of your image is not 1K multiple then you are excluding the last block!
>

Good catch! This is only an issue for ext2 but needs to be verified anyway.

Bart

Re: [oe] [meta-security][RFC 1/2] classes: provide a class for generating dm-verity meta-data images

[Ayoub Zaki]

On 14.04.20 18:19, Bartosz Golaszewski wrote:
> wt., 14 kwi 2020 o 11:17 Ayoub Zaki <ayoub.zaki@embexus.com> napisał(a):
>> Hi,
>>
>> On 14.04.20 11:05, Bartosz Golaszewski wrote:
>>
>> pon., 13 kwi 2020 o 12:58 Ayoub Zaki <ayoub.zaki@embexus.com> napisał(a):
>>
>> basically this class generate a dm-verity hash that needs to be injected
>> inside the initramfs...it's a bit hacky.
>>
>> wouldn't be signing the hash, include the verifiication public key in
>> initramfs more portable ?
>>
>> Sorry, but I don't see how this is a better solution. You then have to
>> store two things somewhere: the hash and its signature. If the
>> fitImage is already signed - there's no reason to have a second
>> signature for the hash: it already comes from a trusted source.
>>
>> This would also inflate the size of the initramfs - not only would it
>> need to include the cryptsetup tools but also additional tools for
>> signature verification.
>>
>>
>> The hash + signature doesn't need to be stored in initramfs in this case but appended to the rootfs image.
>>
>> yes you would need in this case a signature verification tool inside your initramfs and the corresponding public key.
>>
> But how is this better? I know this is how Android does dm-verity, but
> it's not any simpler - I'd argue the actual implementation is more
> complicated.


In case you do OTA Update with your approach you will need to always 
update kernel+initramfs and rootfs even nothing has changed in kernel 
oder initramfs for example to make sure that the Hash inside the 
initramfs is updated!


Another case is if your kernel+initramfs are part of the rootfs how you 
will deal with it ? it's chicken/egg problem.

>
>> It is clearly much better than to poke around with circular dependencies.
>>
> No it's not clearly better. Circular dependencies result from bad
> design and should be fixed. I proposed simple changes that fix them in
> OE-core.
>
>>  From another point the veritysetup is not quite correct:
>>
>> veritysetup --data-block-size=1024 --hash-offset=$SIZE format $OUTPUT $OUTPUT
>>
>>
>> If the size of your image is not 1K multiple then you are excluding the last block!
>>
> Good catch! This is only an issue for ext2 but needs to be verified anyway.
>
> Bart

Mit freundlichen Grüßen / Kind regards

-- 
Ayoub Zaki
Embedded Systems Consultant

Vaihinger Straße 2/1
D-71634 Ludwigsburg


Mobile   : +4917662901545
Email    : ayoub.zaki@embexus.com
Homepage : https://embexus.com
VAT No.  : DE313902634

Re: [oe] [meta-security][RFC 1/2] classes: provide a class for generating dm-verity meta-data images

[Bartosz Golaszewski]

wt., 14 kwi 2020 o 18:28 Ayoub Zaki <ayoub.zaki@embexus.com> napisał(a):
>
>
> On 14.04.20 18:19, Bartosz Golaszewski wrote:
> > wt., 14 kwi 2020 o 11:17 Ayoub Zaki <ayoub.zaki@embexus.com> napisał(a):
> >> Hi,
> >>
> >> On 14.04.20 11:05, Bartosz Golaszewski wrote:
> >>
> >> pon., 13 kwi 2020 o 12:58 Ayoub Zaki <ayoub.zaki@embexus.com> napisał(a):
> >>
> >> basically this class generate a dm-verity hash that needs to be injected
> >> inside the initramfs...it's a bit hacky.
> >>
> >> wouldn't be signing the hash, include the verifiication public key in
> >> initramfs more portable ?
> >>
> >> Sorry, but I don't see how this is a better solution. You then have to
> >> store two things somewhere: the hash and its signature. If the
> >> fitImage is already signed - there's no reason to have a second
> >> signature for the hash: it already comes from a trusted source.
> >>
> >> This would also inflate the size of the initramfs - not only would it
> >> need to include the cryptsetup tools but also additional tools for
> >> signature verification.
> >>
> >>
> >> The hash + signature doesn't need to be stored in initramfs in this case but appended to the rootfs image.
> >>
> >> yes you would need in this case a signature verification tool inside your initramfs and the corresponding public key.
> >>
> > But how is this better? I know this is how Android does dm-verity, but
> > it's not any simpler - I'd argue the actual implementation is more
> > complicated.
>
>
> In case you do OTA Update with your approach you will need to always
> update kernel+initramfs and rootfs even nothing has changed in kernel
> oder initramfs for example to make sure that the Hash inside the
> initramfs is updated!

This is negligible in terms of size and doesn't add to the
complication. I know this, because we've been doing it like this in
real-life applications.

>
>
> Another case is if your kernel+initramfs are part of the rootfs how you
> will deal with it ? it's chicken/egg problem.
>

Of course they're not. I never said that.

It boils down to a matter of taste. If you want to implement a
different approach - there's nothing stopping you from adding some
switch that would result in a different way of storing the root hash.
For now: I'm still waiting for reviews on the OE-code part.

Bart

PS Could you set up your e-mail client to properly format quoted
parts? It's hard to tell who said what and what to respond to.