mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Tobias Waldekranz <tobias@waldekranz.com>
To: barebox@lists.infradead.org
Subject: [PATCH 0/5] dm: Initial work on a device mapper
Date: Thu, 28 Aug 2025 17:05:25 +0200	[thread overview]
Message-ID: <20250828150637.2222474-1-tobias@waldekranz.com> (raw)

Start work on adding a device mapper that is compatible with the
corresponding subsystem in Linux.

This is the foundation of several higher level abstractions, for
example:

- LVM: Linux Volume manager. Dynamically allocates logical volumes
  from one or more storage devices, manages RAID arrays, etc.

- LUKS: Linux Unified Key Setup. Transparent disk
  encryption/decryption.

- dm-verity: Transparent integrity checking of block devices.

This is part of an exploratory project for investigating how we could
boot Infix[1] in a more platform-independent way. I.e., my intention
is to eventually add support for some of the features mentioned above,
assuming we don't hit any major road blocks. The rest of this letter
just gives context for how we got here and where we would like to take
Barebox. If that is not interesting, feel free to stop reading here :)

Our idea is to relegate U-Boot to serve only as a UEFI firmware on the
platforms where we can't escape it, and then do most of our boot logic
in Barebox instead. Primarily we want to do this for two reasons:

1. Being able to ship barebox as an EFI app means we can use the same
   boot logic on x86 machines as we to on everything else.

2. Barebox is a much higher quality code base to work in than
   U-Boot. I'm sorry, but it just is.

Barebox would thus take the place occupied by systemd-boot in many
distro setups. So why not go with systemd-boot?

1. Infix does not run systemd as PID 1, so reusing their bootloader is
   awkward.

2. Infix ships as a single immutable filesystem image, including
   kernel, DTBs, etc. So we want to extract these files from the
   filesystem before booting the kernel. This is not supported by
   systemd-boot, AFAIK - all boot files must live on the ESP.

3. We would like to manage our devices' non-volatile storage with LVM,
   and not be bound to a fixed partition table. This will give us more
   flexibility in growing our image, efficiently having images of
   varying sizes installed, etc.

Therefore, our plan is (roughly):

1. Add dm-verity support
2. Add dm-verity root-hash-signature verification support

With that, we can securely extract kernel+DTB from our filesystem
without having to sign them individually.

3. Add basic LVM support, no RAID or anything, just basic (linear)
   logical volumes.

This will allow us to install multiple versions of Infix on individual
logical volumes, which Barebox can then find and boot from.

4. Add high-level helpers for working with DPS disks and DDI images.

I really like the Linux Userspace API Group's thinking around
Discoverable Partitions Specification (DPS) and Discoverable Disk
Images (DDI). I think it would be great if Barebox had knowledge about
these patterns, and could automatically set up the dm-verity
configuration for a partition when available, for example.

My hope is that this plan sparks some ideas and reflections. If so, I
would love to hear them. If not, sorry for the wall of text :)


[1]: https://github.com/kernelkit/infix/

Tobias Waldekranz (5):
  string: add strtok/strtokv
  dm: Add initial device mapper infrastructure
  dm: linear: Add linear target
  test: self: dm: Add test of linear target
  commands: dmsetup: Basic command set for dm device management

 commands/Kconfig             |  14 ++
 commands/Makefile            |   1 +
 commands/dmsetup.c           | 145 +++++++++++++
 drivers/block/Kconfig        |   2 +
 drivers/block/Makefile       |   1 +
 drivers/block/dm/Kconfig     |  14 ++
 drivers/block/dm/Makefile    |   3 +
 drivers/block/dm/dm-core.c   | 393 +++++++++++++++++++++++++++++++++++
 drivers/block/dm/dm-linear.c | 123 +++++++++++
 drivers/block/dm/dm-target.h |  39 ++++
 include/dm.h                 |  16 ++
 include/string.h             |   2 +
 lib/string.c                 |  66 ++++++
 test/self/Kconfig            |   7 +
 test/self/Makefile           |   1 +
 test/self/dm.c               | 159 ++++++++++++++
 16 files changed, 986 insertions(+)
 create mode 100644 commands/dmsetup.c
 create mode 100644 drivers/block/dm/Kconfig
 create mode 100644 drivers/block/dm/Makefile
 create mode 100644 drivers/block/dm/dm-core.c
 create mode 100644 drivers/block/dm/dm-linear.c
 create mode 100644 drivers/block/dm/dm-target.h
 create mode 100644 include/dm.h
 create mode 100644 test/self/dm.c

-- 
2.43.0




             reply	other threads:[~2025-08-28 17:29 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-28 15:05 Tobias Waldekranz [this message]
2025-08-28 15:05 ` [PATCH 1/5] string: add strtok/strtokv Tobias Waldekranz
2025-08-28 15:05 ` [PATCH 2/5] dm: Add initial device mapper infrastructure Tobias Waldekranz
2025-08-28 15:05 ` [PATCH 3/5] dm: linear: Add linear target Tobias Waldekranz
2025-08-29  5:56   ` Ahmad Fatoum
2025-08-28 15:05 ` [PATCH 4/5] test: self: dm: Add test of " Tobias Waldekranz
2025-08-28 15:05 ` [PATCH 5/5] commands: dmsetup: Basic command set for dm device management Tobias Waldekranz

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=20250828150637.2222474-1-tobias@waldekranz.com \
    --to=tobias@waldekranz.com \
    --cc=barebox@lists.infradead.org \
    /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