Skip to content

Add systemd unit to mount persist partition #1484

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
vkraleti merged 1 commit into from
Feb 12, 2026
Merged

Add systemd unit to mount persist partition #1484

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
16 changes: 16 additions & 0 deletions recipes-bsp/partition/mount-tee-partition/var-lib-tee.mount
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,16 @@
# Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
#
# SPDX-License-Identifier: BSD-3-Clause-Clear

[Unit]
Description=Mount persist partition at /var/lib/tee
Before=local-fs.target

[Mount]
DirectoryMode=0755
What=/dev/disk/by-partlabel/persist
Where=/var/lib/tee
Copy link
Contributor

@lumag lumag Feb 4, 2026

Choose a reason for hiding this comment

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

Is it the only dir which we need to persist? TQFTP engineers also want to have some persistent data.

Copy link
Contributor

@ricardosalveti ricardosalveti Feb 4, 2026

Choose a reason for hiding this comment

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

At least this partition was created with the QTEE justification, but this is a good question.

Copy link
Contributor Author

@vkraleti vkraleti Feb 5, 2026

Choose a reason for hiding this comment

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

If both QTEE & TQFTP both need this partition, is the path /var/lib/tee still valid?

Copy link
Contributor

@ricardosalveti ricardosalveti Feb 5, 2026

Choose a reason for hiding this comment

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

No, but AFAIK we only had QTEE requesting this type of persistent data (as it can be related with security keys and credentials).

Copy link
Contributor

@lumag lumag Feb 5, 2026

Choose a reason for hiding this comment

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

#1445 (comment)
I don't know if it requires the separate partition or if something under /var would be sufficient

Copy link
Contributor

@lool lool Feb 11, 2026

Choose a reason for hiding this comment

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

@ricardosalveti we had a whole other subthread here: qualcomm-linux/qcom-ptool#66

I'm not sure the precious data that we're trying to save is provisioned at factory time. IIUC, there is device-specific licenses that are precious and end up in an app-specific section of the QTEE persistent storage. There are backups in the HLOS' rootfs, and persist is kept separate to avoid paying a fee if one reprovisions the device except for persist.

I agree with the high-level need to have ways to protect precious data. Things I'm personally unclear about:

  • we're special casing the "precious data" situation with the QTEE storage here; what if I have precious data elsewhere?
  • what's the lifecycle around the persist partition and I guess this specific QTEE situation: if we were to support this particular integration, what are the situations we'd want to support? e.g. 1) factory flash with persist as a zeroed partition, HLOS has to mkfs.ext4 it? 2) reflash while preserving persist partition?

I wonder if we should flip this whole design around: provide a generic partition for backups of things that are potential precious and can be used as a recovery point from HLOS. This could look like:

  1. provision an empty "backups" partitions at factory time
  2. have two HLOS first-boot modes: a) restoring files from backup (or one of the backups), b) ignoring backups

I wish this was something somewhat standard that we're not the only ones doing. Would FDO have a story for this?

Copy link
Contributor

@harshaldev27 harshaldev27 Feb 11, 2026

Choose a reason for hiding this comment

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

Hi @lool ,

Allow me to clarify a few things further.

  1. The precious data we are trying to save consists of both one-time factory provisioned data, such as HDCP keys (provisioned via a Trusted Application in OPTEE/QTEE since only TEE writes to this partition) along with data generated by running use-cases (such as licenses acquired over a network and stored here via a Trusted Application) which is only really accessible to TEE (it is encrypted and is only visible to TEE) which is where the whole Global Platform Persistent Object comes into the picture.
  2. The backups are not in HLOS rootfs, they are also in the persist partition, they are used to preserve 'atomicity' of operations on the persist partition. If an operation on a file in the persist partition fails, the backup is used to go back to the last known good state before the operation began. The backup is also used in-case due to a power-cycle a file being written to gets corrupted.
  3. I am not familiar with any use-case running on Qualcomm chipsets where you store security assets (licenses, keys) in some other location apart from RPMB. But like @ricardosalveti , RPMB is not viable for all use-cases.
  4. A re-flash does not need to preserve the contents of the persist partition. We only care about preserving the contents of persist once it is out there in the field. No operation, once the device has been deployed should mess up the contents of this partition. If we decide to re-flash the device, then the partition is supposed to be zeroed out again. This is in-line with the thought process that if the partition has been corrupted, the device anyways needs to be brought back to the factory and reprovisioned (using run-time on-device tools), so wiping it off clean is fine.
  5. A design with a separate 'backups' partition doesn't fit into the TEE Core API specification for GP Persist Objects, where both the files and their backups reside side by side in the same partition. So Qualcomm Linux might provide such a partition, but the specification does not provide a design based around this. Also, we haven't implemented our Secure File System based on separate 'backup' partitions.

Thanks!

Copy link
Contributor

@lool lool Feb 11, 2026

Choose a reason for hiding this comment

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

Hi @harshaldev27 and BTW thanks for the time you're taking in educating me (and I hope others) on some of these topics

  1. The backups are not in HLOS rootfs, they are also in the persist partition, they are used to preserve 'atomicity' of operations on the persist partition. If an operation on a file in the persist partition fails, the backup is used to go back to the last known good state before the operation began. The backup is also used in-case due to a power-cycle a file being written to gets corrupted.

So you're making specific use of the persist filesystem; what happens if that filesystem gets corrupted?

  1. I am not familiar with any use-case running on Qualcomm chipsets where you store security assets (licenses, keys) in some other location apart from RPMB. But like @ricardosalveti , RPMB is not viable for all use-cases.

Personally (on other SoCs) I saw cases of higher level device management certificates (e.g greengrass), device encryption keys for the HLOS, and app level passwords. In an ideal design, these are stored / accessed through TZ, but not always feasible (no TZ, hard to integrate etc.).

  1. A re-flash does not need to preserve the contents of the persist partition. We only care about preserving the contents of persist once it is out there in the field. No operation, once the device has been deployed should mess up the contents of this partition. If we decide to re-flash the device, then the partition is supposed to be zeroed out again. This is in-line with the thought process that if the partition has been corrupted, the device anyways needs to be brought back to the factory and reprovisioned (using run-time on-device tools), so wiping it off clean is fine.

We might need the right terminology, how would you call "I want to fix the system after a broken OTA, but keep the precious data"? Reprovision the HLOS?

  1. A design with a separate 'backups' partition doesn't fit into the TEE Core API specification for GP Persist Objects, where both the files and their backups reside side by side in the same partition. So Qualcomm Linux might provide such a partition, but the specification does not provide a design based around this. Also, we haven't implemented our Secure File System based on separate 'backup' partitions.

I guess this is due to the atomic thingy you mentioned earlier; it sounds like some A/B mechanism within the persist partition.

Overall, it feels like this TEE space is solving its problem in its bubble for itself, but its lifecycle requirements require some HLOS integration (provisioning, boot, recovery). I'm trying to see if this can be generalized so that we don't do a TEE-specific or – worse – a QTEE-specific HLOS integration.

Copy link
Contributor

@ricardosalveti ricardosalveti Feb 11, 2026

Choose a reason for hiding this comment

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

At the moment I would say that this TEE-specific, and compatible with both QTEE and OP-TEE (we had similar needs in foundries, using a separated partition for OP-TEE).

Copy link
Member

@b49020 b49020 Feb 12, 2026

Choose a reason for hiding this comment

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

@lool

Overall, it feels like this TEE space is solving its problem in its bubble for itself

I can understand your comments from standard Linux distros point of view especially Debian where the TEE based use-cases for IoT/Mobile/Edge systems are less known or implemented. Although hardware TPM based use-cases are more prevalent there. Many of the TPM related use-cases can be supported with TEE especially with the support of TEE based firmware TPMs. The TEE based use-cases are mostly prevalent in Yocto and Android environments. But for sure standard distros gaining momentum in the IoT/Mobile/Edge systems, we surely would need to get at-least Debian support for TEE based security use-cases.

I wish this was something somewhat standard that we're not the only ones doing. Would FDO have a story for this?

Yeah, IIRC from my Linaro days folks already started exploring standard FDO provisioning using Fedora with OP-TEE as well. Not sure the current status of that work. Anyhow, we are not alone here as all other silicon vendors in the IoT space offer TEE solutions but I feel the standard distros integration is still missing.

but its lifecycle requirements require some HLOS integration (provisioning, boot, recovery).

That's right since TEE environments (whether QTEE/OP-TEE) is pretty constrained due to small footprint design goals. For that reason, it depends on HLOS for all the file-system services for secure storage. And yes there is use of RPMB for secure storage as well but it's pretty limited in terms of storage space.

Regarding usage of separate partition for secure storage, it usually becomes handy when you have to deal with A/B firmware and OS updates with the rollback counters stored in that secure storage based on the separate partition. That's additional use-case to what has been mentioned earlier related to secrets (key/data) provisioning.

Type=ext4

[Install]
WantedBy=local-fs.target
25 changes: 25 additions & 0 deletions recipes-bsp/partition/mount-tee-partition_1.0.bb
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,25 @@
SUMMARY = "Systemd unit to mount persist parition at /var/lib/tee"
DESCRIPTION = "Mount persist partition at /var/lib/tee to store \
encryped data and support security functions"
LICENSE = "BSD-3-Clause-Clear"
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/BSD-3-Clause-Clear;md5=7a434440b651f4a472ca93716d01033a"

SRC_URI = "file://var-lib-tee.mount"

inherit allarch features_check systemd
REQUIRED_DISTRO_FEATURES = "systemd"

INHIBIT_DEFAULT_DEPS = "1"

S = "${UNPACKDIR}"

do_compile[noexec] = "1"

do_install() {
install -Dm 0644 ${UNPACKDIR}/var-lib-tee.mount \
${D}${systemd_unitdir}/system/var-lib-tee.mount
}

PACKAGES = "${PN}"

SYSTEMD_SERVICE:${PN} = "var-lib-tee.mount"
Loading