________________________________ From: Ming Huang huangming@linux.alibaba.com Sent: 24 January 2022 09:22 To: tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org Cc: Manish Pandey2 Manish.Pandey2@arm.com; Jeenu Viswambharan Jeenu.Viswambharan@arm.com Subject: About arm_validate_ns_entrypoint in arm_pm.c

Hi,

arm_validate_ns_entrypoint() in plat/arm/common/arm_pm.c check ARM_NS_DRAM1_BASE and ARM_NS_DRAM2_BASE only, for some platform there are include more than two non-secure dram areas.

The platform callback "validate_ns_entrypoint" does eventually calls platform specific <plat>_validate_ns_entrypoint(). The Arm platforms has its implementation of checking if NS entrypoint lies in either of the DRAMs. There are few other platforms which have their own implementation e.g.

* a3700_validate_ns_entrypoint() - Always returns success. * sunxi_validate_ns_entrypoint() - Similar check as what you asked for

It will bring dependencies between TF-A and physical memory space which can get from uefi atfer memory initialization, if arm_validate_ns_entrypoint() include the entire physical memory space.

In my mind, the kernel should guarantee the validity of entry point. So why this check is need?

IMO, the reason for this callback is to have a framework in TF-A to check NS entrypoint , but as i said earlier platform is free to implement whatever it seems enough for it.

Thanks, Ming

Hi Soby & Manish

Okay, got it. Thanks for your reply.

Best Regards, Ming

在 1/24/22 8:36 PM, Soby Mathew 写道:

Hi Ming, The primary reason is that a malicious NS software can provide a Secure world address as the ns_entrypoint and cause the CPU to jump to the address specified for execution. This execution will most likely fail due to various reasons but it is an attack vector. Hence it is essential that EL3 verifies the incoming address specified and ensure that it lies in the NS memory map to mitigate against this threat.

Best Regards Soby Mathew

From: Manish Pandey2 via TF-A tf-a@lists.trustedfirmware.org Sent: 24 January 2022 11:08 To: Ming Huang huangming@linux.alibaba.com; tf-a@lists.trustedfirmware.org Cc: Jeenu Viswambharan Jeenu.Viswambharan@arm.com Subject: [TF-A] Re: About arm_validate_ns_entrypoint in arm_pm.c

---

From: Ming Huang <huangming@linux.alibaba.commailto:huangming@linux.alibaba.com> Sent: 24 January 2022 09:22 To: tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org> Cc: Manish Pandey2 <Manish.Pandey2@arm.commailto:Manish.Pandey2@arm.com>; Jeenu Viswambharan <Jeenu.Viswambharan@arm.commailto:Jeenu.Viswambharan@arm.com> Subject: About arm_validate_ns_entrypoint in arm_pm.c

Hi,

...

arm_validate_ns_entrypoint() in plat/arm/common/arm_pm.c check ARM_NS_DRAM1_BASE and ARM_NS_DRAM2_BASE only, for some platform there are include more than two non-secure dram areas.

The platform callback "validate_ns_entrypoint" does eventually calls platform specific <plat>_validate_ns_entrypoint(). The Arm platforms has its implementation of checking if NS entrypoint lies in either of the DRAMs. There are few other platforms which have their own implementation e.g.

• a3700_validate_ns_entrypoint() - Always returns success.
• sunxi_validate_ns_entrypoint() - Similar check as what you asked for

...

It will bring dependencies between TF-A and physical memory space which can get from uefi atfer memory initialization, if arm_validate_ns_entrypoint() include the entire physical memory space.

...

In my mind, the kernel should guarantee the validity of entry point. So why this check is need?

IMO, the reason for this callback is to have a framework in TF-A to check NS entrypoint , but as i said earlier platform is free to implement whatever it seems enough for it.

Thanks, Ming