Add systemd unit to mount persist partition#1484
Add systemd unit to mount persist partition#1484vkraleti merged 1 commit intoqualcomm-linux:masterfrom
persist partition#1484Conversation
| [Mount] | ||
| DirectoryMode=0755 | ||
| What=/dev/disk/by-partlabel/persist | ||
| Where=/var/lib/tee |
There was a problem hiding this comment.
Is it the only dir which we need to persist? TQFTP engineers also want to have some persistent data.
There was a problem hiding this comment.
At least this partition was created with the QTEE justification, but this is a good question.
There was a problem hiding this comment.
If both QTEE & TQFTP both need this partition, is the path /var/lib/tee still valid?
There was a problem hiding this comment.
No, but AFAIK we only had QTEE requesting this type of persistent data (as it can be related with security keys and credentials).
There was a problem hiding this comment.
#1445 (comment)
I don't know if it requires the separate partition or if something under /var would be sufficient
There was a problem hiding this comment.
@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:
- provision an empty "backups" partitions at factory time
- 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?
There was a problem hiding this comment.
Hi @lool ,
Allow me to clarify a few things further.
- 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.
- 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.
- 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.
- 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.
- 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!
There was a problem hiding this comment.
Hi @harshaldev27 and BTW thanks for the time you're taking in educating me (and I hope others) on some of these topics
- 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?
- 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.).
- 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?
- 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.
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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.
Test run workflowTest jobs for commit 955cbe8
All jobs summary
|
Test run workflowTest jobs for commit 0263a8b
All jobs summary
|
Test Results 46 files + 19 151 suites +124 2h 50m 28s ⏱️ + 1h 51m 47s For more details on these failures, see this check. Results for commit a918d93. ± Comparison against base commit a8424ba. ♻️ This comment has been updated with latest results. |
Test run workflowTest jobs for commit 0263a8b
All jobs summary
|
Add a systemd .mount unit to ensure the `persist` partition is mounted at /var/lib/tee. This directory is used by QTEE to store encrypted data, and mounting it early in the boot process ensures the required filesystem is available before services that depend on it start. Signed-off-by: Viswanath Kraleti <viswanath.kraleti@oss.qualcomm.com>
lool
left a comment
lool
left a comment
There was a problem hiding this comment.
Ricardo asked for my review, I see other approval coming in, so soon auto-merge will kick-in... I don't want to stand blocking this (I'm not a meta-qcom maintainer anyway).
I don't particularly mind this or that implementation, this seems to be a copy-paste of what was done in the past. I do find this overall integration would benefit from having at the very least a spec that we could refer to and would explain the big picture, and then the implementation would follow.
I personally didn't quite conclude in understanding the line of thinking and tradeoffs that led to this implementation, I feel a more general purpose implementation could be delivered, but again, not a meta-qcom maintainer. 🤷♂️
I believe it is a valid scenario and that we should try proposing the idea for a TEE-based persistent partition (e.g. https://uapi-group.org/specifications/specs/discoverable_partitions_specification/), then we can update the implementation based on the upstream feedback. The actual problem is that secure storage is not something commonly used by distros, so this needs more discussion. |
Test run workflowTest jobs for commit a918d93
All jobs summary
|
8 participants
Add a systemd .mount unit to mount
persistpartition at /var/lib/tee.This directory is used by QTEE to store encrypted data.