Where to add support for persist partition for Hamoa and Talos?

[harshaldev27]

Hello,

We have request for supporting QTEE use-cases with Hamoa and Talos. This as per discussions in other threads, requires support for the persist partition again so that QTEE can store one-time provisioned keys and encrypted security assets similar to OPTEE.

I can see that contrary to qcs6490 and qcs9100 where we added support for persist partition in LUN 5 for the UFS storage:
https://github.com/qualcomm-linux/qcom-ptool/blob/main/platforms/qcs9100-ride-sx/ufs/partitions.conf#L109
https://github.com/qualcomm-linux/qcom-ptool/blob/main/platforms/qcs6490-rb3gen2/ufs/partitions.conf#L113

The UFS storage on Hamoa is not used for firmware image partitions, where we can add support for a separate persist partition as well. It seems to be using UFS only for Linux efi and rootfs images.
https://github.com/qualcomm-linux/qcom-ptool/blob/main/platforms/iq-x7181-evk/ufs/partitions.conf

For firmware images, we have the SPINOR: https://github.com/qualcomm-linux/qcom-ptool/blob/main/platforms/iq-x7181-evk/spinor/partitions.conf
I need inputs on whether it is okay to support persist through SPINOR storage for Hamoa.

For Talos on the other hand, I can see that both boards with EMMC already support persist:
https://github.com/qualcomm-linux/qcom-ptool/blob/main/platforms/iq-615-evk/emmc/partitions.conf#L77
https://github.com/qualcomm-linux/qcom-ptool/blob/main/platforms/qcs615-ride/emmc/partitions.conf#L77

But UFS is missing support for persist. Perhaps, it can be added as the last partition just before:
https://github.com/qualcomm-linux/qcom-ptool/blob/main/platforms/qcs615-ride/ufs/partitions.conf#L98

Do let me know concerns on this as well.

Regards,
Harshal

[lumag]

Open a PR instead of having lengthy discussions.

[ricardosalveti]

For UFS-based targets I would prefer the partitioning scheme to be aligned with SystemReady and not have it as part of the main system LUN, as we expect installers or other distros to replace this LUN entirely (and why we added to LUN 5 on a few targets). eMMC is different as we need all partitions available without such separation.

For Hamoa, are we able to have it as part of SPINOR? At least the separation will be clear there.

[harshaldev27]

Sure @ricardosalveti , I am fine with defining a separate LUN5 on Talos only for persist. I am also okay with using SPINOR on Hamoa for persist. I believe once the partition are defined, the same PR form @vkraleti should be able to mount and format the partition?
qualcomm-linux/meta-qcom#1733

[vkraleti]

SPI-NOR on Hamoa is only 64MB. I don't think it is possible to reserve 32MB in it for key storage

[harshaldev27]

Ah, you are correct @vkraleti . I remember you mentioned this earlier but it skipped my mind. I believe that leaves us with UFS/NVMe path only. I guess UFS and NVMe for Hamoa are mutually exclusive and either one is available on the board. Perhaps then for persist we need a separate LUN on UFS and a new partition altogether on NVMe?

[ricardosalveti]

For UFS we could have a separated LUN, but then with NVMe I'm not sure what would be the best way to handle this as we do expect distros to take full control of it. Debian might use a different partitioning scheme for NVMe, same for other distros, so at this point we are making distro-specific choices here, and that is also not aligned with SystemReady.

@lool ^ fyi

[lumag]

For UFS we could have a separated LUN, but then with NVMe I'm not sure what would be the best way to handle this as we do expect distros to take full control of it. Debian might use a different partitioning scheme for NVMe, same for other distros, so at this point we are making distro-specific choices here, and that is also not aligned with SystemReady.

@lool ^ fyi

What about using separate NVMe namespaces? We probably can separate a namespace for persist data (Which might be not limited to the TEE persist partition).

[lool]

Even if SPINOR was backing the persist partition, the idea behind that partition is to have a HLOS managed partition for this data. I'm trying to wrap my mind on what this means with respect to SystemReady.

If I recap what we want:

• for QTEE integration in QLI (meta-qcom for now, Debian might follow), we deem it's safer to keep the precious persistent data in a dedicated partition; this needs to be provisioned from early on in the OS lifecycle
• we also want SystemReady compatibility, which is about the boot firmware to OS interface and ensure cross-OS and cross-device compatibility

Right now, QLI (meta-qcom and qcom-deb-images) is provisioned by flashing a preinstalled image on a device (no installer) and provides both boot firmware and OS in one flat image. We can look at SystemReady compatibility both ways:

1. from a device that was flashed with QLI, can I install another SystemReady compatible OS?
2. from a device that is running a SystemReady compatible bootloader, can I install QLI?

I think 1) is where Ricardo is saying it would be beneficial to hide the persist partition from places another OS might touch. That would allow preserving precious data if someone was to return to QLI later, or perhaps we could even leverage persist from another OS.

2. is very limited since we only support our own devices; it's still interesting to consider reinstalling QLI on a previously provisioned device.

I agree it kind of makes sense to have persist in a separate LUN to give it more chances of survival.

Would you think it makes sense to request and use an unique GPT UUID for the persist partition? we could request its addition to:
https://uapi-group.org/specifications/specs/discoverable_partitions_specification/
this would allow:

• automatic discovery from QLI (rather than relying on the "persist" name)
• automatic discovery from other OSes and even other TEE implementations

We also need to clarify when in the device lifecycle the persist partition should be flashed: if it's always in our images, chances that someone flashes an empty one over the current one are high. We could perhaps protect it in some way after provisioning?

[harshaldev27]

I guess we're all aligned then on the following:

1. For UFS, a separate LUN for persist should be present to avoid the partition being touched by other OSes or OS installers along with other reasons mentioned by @lool.
2. For NVMe, for short-term I agree with @lumag that we could turn to namespaces but in the long-term it makes more sense as @lool said to have an assigned UUID for it in above specification. Once we have that, neither QLI nor any other SystemReady compatible OS needs a separate systemd mount unit for mounting the partition by searching for its name.

On the point of protection, in the Android world where we've delivered this partition for years, it exists in our flashed images and it reset on every flash. We simply communicate this to the customer and we've had no complaints. And so, in my opinion any protection which avoids a re-flash of persist is a good-to-have rather than a strict requirement right now. Also, if we were to provide this protection, we would also need to provide a way to the customer to wipe clean the protected persist partition.

I have another question. I know that persist partition exists downstream for Hamoa. How come it didn't come by default in this PR #77? I haven't checked where persist was defined in downstream, but I know we have it working there. @vivpuar can you comment?

[vivpuar]

I have another question. I know that persist partition exists downstream for Hamoa. How come it didn't come by default in this PR #77? I haven't checked where persist was defined in downstream, but I know we have it working there. @vivpuar can you comment?

@harshaldev27 I'm not sure about Hamoa downstream, @shoudil can answer . PR#52 is initial PR for partition files for Hamoa.

[ricardosalveti]

I haven't checked where persist was defined in downstream, but I know we have it working there.

Downstream you mean windows? I guess the changes were proposed following the same pattern we have on other targets.

[harshaldev27]

Yes, on Hamoa Windows we have a separate directory for storing the Encrypted TA files in a dedicated location. I couldn't get exact information on where this partition is defined and how this is being mounted for Windows. It seems for now that Microsoft is taking care of it there. I'll have to dig more on it.

[harshaldev27]

For UFS we could have a separated LUN, but then with NVMe I'm not sure what would be the best way to handle this as we do expect distros to take full control of it. Debian might use a different partitioning scheme for NVMe, same for other distros, so at this point we are making distro-specific choices here, and that is also not aligned with SystemReady.
@lool ^ fyi

What about using separate NVMe namespaces? We probably can separate a namespace for persist data (Which might be not limited to the TEE persist partition).

Hi @lumag , can you explain how we can define a namespace in the partition.conf file? Is there a specific parameter we can use like --namespace?

[lumag]

can you explain how we can define a namespace in the partition.conf file? Is there a specific parameter we can use like --namespace?

I have no idea, sorry. It well might be that it is not supported ATM (also one would need to implement support for creating re-partitioning the NVMe.