Hi Kuldeep,
A data point from retail hardware, in case it is useful for this series: on an ASUS Zenbook A14 UX3407NA (Glymur, X2E-88-100, BIOS UX3407NA.315) the TPM TA is not reachable as QTEE service 81, but it is present as the QSEECOM application "qcom.tz.tpm".
With the qcomtee driver on a 7.3-rc3 based kernel, QTEE reports version 5.2.0, and service discovery finds neither 81 (TPM) nor 413 (UEFI secure app). On the same boot, qseecom (version 0x1402000) works and backs efivars through "qcom.tz.uefisecapp" (app id 7). An app-id lookup for "qcom.tz.tpm" returns app id 1; a made-up name returns -ENOENT.
The Windows driver for this machine agrees: QcTrEE8480.inf configures the TPM service with AppName="qcom.tz.tpm", SecureApp=1, LoadApp=0 (preloaded by firmware). The EFI configuration table carries the TPMEventLog and TPMFinalLog entries, so the firmware TPM is active.
Through that app, using a QSEECOM transport (based on Xilin Wu's out-of-tree SC8280XP driver: QUERY_INFO_2 / SEND_COMMAND with a CRB-style control area, here at 0x81d10000), /dev/tpm0 works: TPM 2.0, manufacturer QCOM, vendor string "xCG fTPM", firmware 0x40000, real PCR 0-7 values, GetRandom, ECC and RSA-2048 primaries, sign and verify, and a sealed object that persists across reboots.
So, as far as I can tell, retail Glymur laptops may ship firmware on which this driver finds no TPM, while the same TA is available over QSEECOM.
The same applies to the prerequisite series that moves uefisecapp to QCOMTEE [1]: on this firmware service 413 is absent and EFI variables work only through the QSEECOM uefisecapp. If the QSEECOM path were dropped for Glymur, efivars would stop working on this machine, so it would be good to keep it as a fallback when the QTEE service is not found.
Two questions:
- Is service 81 expected to appear on retail firmware through an update, or is it specific to the CRD firmware? - Would you consider a QSEECOM-based path for such firmware? I am happy to test this series, or any other service UID you would like checked, on this machine, and to share the transport code.
[1] https://lore.kernel.org/lkml/20260722-qcom_uefisecapp_migrate_qcomtee-v2-0-b...
Thanks, zeroknots
Assisted-by: LLM (analysis and drafting; the measurements were made on the hardware and reviewed by me)
On 01-10-2026 11:20, zeroknots wrote:
Hi Kuldeep,
A data point from retail hardware, in case it is useful for this series: on an ASUS Zenbook A14 UX3407NA (Glymur, X2E-88-100, BIOS UX3407NA.315) the TPM TA is not reachable as QTEE service 81, but it is present as the QSEECOM application "qcom.tz.tpm".
Thanks for reaching out, Kindly check below.
With the qcomtee driver on a 7.3-rc3 based kernel, QTEE reports version 5.2.0, and service discovery finds neither 81 (TPM) nor 413 (UEFI secure app). On the same boot, qseecom (version 0x1402000) works and backs efivars through "qcom.tz.uefisecapp" (app id 7). An app-id lookup for "qcom.tz.tpm" returns app id 1; a made-up name returns -ENOENT.
The Windows driver for this machine agrees: QcTrEE8480.inf configures the TPM service with AppName="qcom.tz.tpm", SecureApp=1, LoadApp=0 (preloaded by firmware). The EFI configuration table carries the TPMEventLog and TPMFinalLog entries, so the firmware TPM is active.
Through that app, using a QSEECOM transport (based on Xilin Wu's out-of-tree SC8280XP driver: QUERY_INFO_2 / SEND_COMMAND with a CRB-style control area, here at 0x81d10000), /dev/tpm0 works: TPM 2.0, manufacturer QCOM, vendor string "xCG fTPM", firmware 0x40000, real PCR 0-7 values, GetRandom, ECC and RSA-2048 primaries, sign and verify, and a sealed object that persists across reboots.
So, as far as I can tell, retail Glymur laptops may ship firmware on which this driver finds no TPM, while the same TA is available over QSEECOM.
The same applies to the prerequisite series that moves uefisecapp to QCOMTEE [1]: on this firmware service 413 is absent and EFI variables work only through the QSEECOM uefisecapp. If the QSEECOM path were dropped for Glymur, efivars would stop working on this machine, so it would be good to keep it as a fallback when the QTEE service is not found.
Two questions:
- Is service 81 expected to appear on retail firmware through an update, or is it specific to the CRD firmware?
Yes, there's spinor update(bootfw2.mbn) needed which is in progress to publish as QTEE side changes were already merged long back. Roughly it takes ~1month(ideal scenario) to get firmware changes available but somehow it's taking more this time.
I think i should have captured this dependency info in my series cover letter to avoid any confusion.
With the changes, service uid 81 will be available and won't see qcomtee driver issue log there.
- Would you consider a QSEECOM-based path for such firmware? I am happy to test this series, or any other service UID you would like checked, on this machine, and to share the transport code.
Qseecom-based firmware path is not recommend approach as it's not generic and less scalable leaving less room for expanding featuresets. qcomtee uses mink-ipc based model which does all interaction with TA with just 2 scm calls and is very much scalable compared to qseecom.
So, we are planning to use mink-ipc based qcomtee path only and I'll drop an update once QTEE firmware changes are available in meta builds. I'd be happy you to try it out and give any suggestions!
On Mon, Oct 05, 2026 at 12:27:40PM +0530, Kuldeep Singh wrote:
On 01-10-2026 11:20, zeroknots wrote:
Hi Kuldeep,
A data point from retail hardware, in case it is useful for this series: on an ASUS Zenbook A14 UX3407NA (Glymur, X2E-88-100, BIOS UX3407NA.315) the TPM TA is not reachable as QTEE service 81, but it is present as the QSEECOM application "qcom.tz.tpm".
Thanks for reaching out, Kindly check below.
With the qcomtee driver on a 7.3-rc3 based kernel, QTEE reports version 5.2.0, and service discovery finds neither 81 (TPM) nor 413 (UEFI secure app). On the same boot, qseecom (version 0x1402000) works and backs efivars through "qcom.tz.uefisecapp" (app id 7). An app-id lookup for "qcom.tz.tpm" returns app id 1; a made-up name returns -ENOENT.
The Windows driver for this machine agrees: QcTrEE8480.inf configures the TPM service with AppName="qcom.tz.tpm", SecureApp=1, LoadApp=0 (preloaded by firmware). The EFI configuration table carries the TPMEventLog and TPMFinalLog entries, so the firmware TPM is active.
Through that app, using a QSEECOM transport (based on Xilin Wu's out-of-tree SC8280XP driver: QUERY_INFO_2 / SEND_COMMAND with a CRB-style control area, here at 0x81d10000), /dev/tpm0 works: TPM 2.0, manufacturer QCOM, vendor string "xCG fTPM", firmware 0x40000, real PCR 0-7 values, GetRandom, ECC and RSA-2048 primaries, sign and verify, and a sealed object that persists across reboots.
So, as far as I can tell, retail Glymur laptops may ship firmware on which this driver finds no TPM, while the same TA is available over QSEECOM.
The same applies to the prerequisite series that moves uefisecapp to QCOMTEE [1]: on this firmware service 413 is absent and EFI variables work only through the QSEECOM uefisecapp. If the QSEECOM path were dropped for Glymur, efivars would stop working on this machine, so it would be good to keep it as a fallback when the QTEE service is not found.
No, the existing paths are not going to be stripped.
Two questions:
- Is service 81 expected to appear on retail firmware through an update, or is it specific to the CRD firmware?
Yes, there's spinor update(bootfw2.mbn) needed which is in progress to publish as QTEE side changes were already merged long back. Roughly it takes ~1month(ideal scenario) to get firmware changes available but somehow it's taking more this time.
I think i should have captured this dependency info in my series cover letter to avoid any confusion.
With the changes, service uid 81 will be available and won't see qcomtee driver issue log there.
You are responding to the user who uses a COTS commercial device. Are you suggesting that the user can somehow update the firmware on that device?
- Would you consider a QSEECOM-based path for such firmware? I am happy to test this series, or any other service UID you would like checked, on this machine, and to share the transport code.
Qseecom-based firmware path is not recommend approach as it's not generic and less scalable leaving less room for expanding featuresets. qcomtee uses mink-ipc based model which does all interaction with TA with just 2 scm calls and is very much scalable compared to qseecom.
So, we are planning to use mink-ipc based qcomtee path only and I'll drop an update once QTEE firmware changes are available in meta builds. I'd be happy you to try it out and give any suggestions!
I feel it really sad that the team (again) ignores existing available devices. Yes, QSEECOM is legacy, etc., etc. However we must make sure that devices are being sold can be used.
I guess, at this point, the best course of action would be for Xilin Wu to submit the QSEECOM driver upstream. Xiling, could you please do it?
Two questions:
- Is service 81 expected to appear on retail firmware through an update, or is it specific to the CRD firmware?
Yes, there's spinor update(bootfw2.mbn) needed which is in progress to publish as QTEE side changes were already merged long back. Roughly it takes ~1month(ideal scenario) to get firmware changes available but somehow it's taking more this time.
I think i should have captured this dependency info in my series cover letter to avoid any confusion.
With the changes, service uid 81 will be available and won't see qcomtee driver issue log there.
You are responding to the user who uses a COTS commercial device. Are you suggesting that the user can somehow update the firmware on that device?
Ahh, for COTS devices as one cannot replace firmware so it's better to use qseecom path in that case. For latest ones, one can switch to qcomtee based approach.
If Xilin already has qseecom interface written then it's best to have it for the COTS devices.
On 10/5/2026 3:24 PM, Dmitry Baryshkov wrote:
On Mon, Oct 05, 2026 at 12:27:40PM +0530, Kuldeep Singh wrote:
On 01-10-2026 11:20, zeroknots wrote:
Hi Kuldeep,
A data point from retail hardware, in case it is useful for this series: on an ASUS Zenbook A14 UX3407NA (Glymur, X2E-88-100, BIOS UX3407NA.315) the TPM TA is not reachable as QTEE service 81, but it is present as the QSEECOM application "qcom.tz.tpm".
Thanks for reaching out, Kindly check below.
With the qcomtee driver on a 7.3-rc3 based kernel, QTEE reports version 5.2.0, and service discovery finds neither 81 (TPM) nor 413 (UEFI secure app). On the same boot, qseecom (version 0x1402000) works and backs efivars through "qcom.tz.uefisecapp" (app id 7). An app-id lookup for "qcom.tz.tpm" returns app id 1; a made-up name returns -ENOENT.
The Windows driver for this machine agrees: QcTrEE8480.inf configures the TPM service with AppName="qcom.tz.tpm", SecureApp=1, LoadApp=0 (preloaded by firmware). The EFI configuration table carries the TPMEventLog and TPMFinalLog entries, so the firmware TPM is active.
Through that app, using a QSEECOM transport (based on Xilin Wu's out-of-tree SC8280XP driver: QUERY_INFO_2 / SEND_COMMAND with a CRB-style control area, here at 0x81d10000), /dev/tpm0 works: TPM 2.0, manufacturer QCOM, vendor string "xCG fTPM", firmware 0x40000, real PCR 0-7 values, GetRandom, ECC and RSA-2048 primaries, sign and verify, and a sealed object that persists across reboots.
So, as far as I can tell, retail Glymur laptops may ship firmware on which this driver finds no TPM, while the same TA is available over QSEECOM.
The same applies to the prerequisite series that moves uefisecapp to QCOMTEE [1]: on this firmware service 413 is absent and EFI variables work only through the QSEECOM uefisecapp. If the QSEECOM path were dropped for Glymur, efivars would stop working on this machine, so it would be good to keep it as a fallback when the QTEE service is not found.
No, the existing paths are not going to be stripped.
Two questions:
- Is service 81 expected to appear on retail firmware through an update, or is it specific to the CRD firmware?
Yes, there's spinor update(bootfw2.mbn) needed which is in progress to publish as QTEE side changes were already merged long back. Roughly it takes ~1month(ideal scenario) to get firmware changes available but somehow it's taking more this time.
I think i should have captured this dependency info in my series cover letter to avoid any confusion.
With the changes, service uid 81 will be available and won't see qcomtee driver issue log there.
You are responding to the user who uses a COTS commercial device. Are you suggesting that the user can somehow update the firmware on that device?
- Would you consider a QSEECOM-based path for such firmware? I am happy to test this series, or any other service UID you would like checked, on this machine, and to share the transport code.
Qseecom-based firmware path is not recommend approach as it's not generic and less scalable leaving less room for expanding featuresets. qcomtee uses mink-ipc based model which does all interaction with TA with just 2 scm calls and is very much scalable compared to qseecom.
So, we are planning to use mink-ipc based qcomtee path only and I'll drop an update once QTEE firmware changes are available in meta builds. I'd be happy you to try it out and give any suggestions!
I feel it really sad that the team (again) ignores existing available devices. Yes, QSEECOM is legacy, etc., etc. However we must make sure that devices are being sold can be used.
I guess, at this point, the best course of action would be for Xilin Wu to submit the QSEECOM driver upstream. Xiling, could you please do it?
I'm also sad to hear that the proposed qcomtee path isn't even supported on Glymur, and yet the Qualcomm team is ignoring QSEECOM, which is used on all the devices currently being sold. I might submit the driver upstream, but I can't promise anything.
op-tee@lists.trustedfirmware.org
-
Dmitry Baryshkov -
Kuldeep Singh -
Xilin Wu -
zeroknots