Hi Jan,

This handler is expected to ensure that the address is valid in the client translation regime. Per the porting guide, the handler is optional and depends on the software stack running on the platform.

If you can guarantee that the entrypoint address will always be valid in the client translation regime, then the handler need not be implemented e.g. a client always uses physical address for the entrypoint.

The Tegra handler can be enhanced to ensure that the client provided entrypoint address is a valid memory address, at the very least.

-Varun

-----Original Message----- From: Jan Kiszka jan.kiszka@web.de Sent: Saturday, September 26, 2020 6:22 AM To: tf-a@lists.trustedfirmware.org; Jeenu Viswambharan jeenu.viswambharan@arm.com; Peng Fan peng.fan@nxp.com; Varun Wadekar vwadekar@nvidia.com; Siva Durga Prasad Paladugu siva.durga.paladugu@xilinx.com; Jacky Bai ping.bai@nxp.com Subject: When to implement plat_sdei_validate_entry_point?

External email: Use caution opening links or attachments

Hi,

I'm adding basic SDEI support to the zynqmp platform (just private event 0 for now), and I'm wondering what to do with plat_sdei_validate_entry_point().

Looking around what other SDEI implementations did, neither tegra nor the recently added imx8mm implement this and rather rely on the empty stub from plat/common/aarch64/plat_common.c. As zynqmp also pulls in plat/arm/common/arm_common.c and doesn't find any arm_validate_ns_entrypoint, my search started.

Is there anything that makes the check for tegra and imx8mm unneeded? Or are they both broken and should better use plat_sdei_validate_entry_point from plat/arm/common/arm_common.c?

Thanks, Jan

...

How should TF-A possibly know how its clients will use SDEI? As a system integrator, I might know this, but not as a TF-A developer.

I agree, this is a problem for a TF-A developer.

...

If I understand the check correctly now, it's only there to protect the client from itself. In the worst case, an invalid entry point will cause the client to crash or do other nonsense but it will not affect the integrity of TF-A, right?

Right. Even if TF-A adds checks to make sure that the address lies inside DRAM or SRAM memory, the system might have configured that memory for something else and it might not be accessible to the CPU. So, TF-A can only do so much.

We should debate about the security implications of the approach and then come up with a policy that works. There can be different schools of thought - do nothing or at least avoid being the bazooka that gets used to attack the system. But this policy should apply to all the entrypoint addresses that are passed on to TF-A e.g. CPU entrypoint sent with PSCI_CPU_ON.

...

Also, the SDEI spec does not demand that an implementation performs such checks. All that makes it optional.

That's my understanding too.

-----Original Message----- From: Jan Kiszka jan.kiszka@web.de Sent: Sunday, September 27, 2020 1:22 AM To: Varun Wadekar vwadekar@nvidia.com; tf-a@lists.trustedfirmware.org; Jeenu Viswambharan jeenu.viswambharan@arm.com; Peng Fan peng.fan@nxp.com; Siva Durga Prasad Paladugu siva.durga.paladugu@xilinx.com; Jacky Bai ping.bai@nxp.com Subject: Re: When to implement plat_sdei_validate_entry_point?

External email: Use caution opening links or attachments

Hi Varun,

On 26.09.20 19:55, Varun Wadekar wrote:

Hi Jan,

This handler is expected to ensure that the address is valid in the client translation regime. Per the porting guide, the handler is optional and depends on the software stack running on the platform.

If you can guarantee that the entrypoint address will always be valid in the client translation regime, then the handler need not be implemented e.g. a client always uses physical address for the entrypoint.

How should TF-A possibly know how its clients will use SDEI? As a system integrator, I might know this, but not as a TF-A developer.

The Tegra handler can be enhanced to ensure that the client provided entrypoint address is a valid memory address, at the very least.

If I understand the check correctly now, it's only there to protect the client from itself. In the worst case, an invalid entry point will cause the client to crash or do other nonsense but it will not affect the integrity of TF-A, right? Also, the SDEI spec does not demand that an implementation performs such checks. All that makes it optional.

Thanks, Jan

-Varun

-----Original Message----- From: Jan Kiszka jan.kiszka@web.de Sent: Saturday, September 26, 2020 6:22 AM To: tf-a@lists.trustedfirmware.org; Jeenu Viswambharan jeenu.viswambharan@arm.com; Peng Fan peng.fan@nxp.com; Varun Wadekar vwadekar@nvidia.com; Siva Durga Prasad Paladugu siva.durga.paladugu@xilinx.com; Jacky Bai ping.bai@nxp.com Subject: When to implement plat_sdei_validate_entry_point?

External email: Use caution opening links or attachments

Hi,

I'm adding basic SDEI support to the zynqmp platform (just private event 0 for now), and I'm wondering what to do with plat_sdei_validate_entry_point().

Looking around what other SDEI implementations did, neither tegra nor the recently added imx8mm implement this and rather rely on the empty stub from plat/common/aarch64/plat_common.c. As zynqmp also pulls in plat/arm/common/arm_common.c and doesn't find any arm_validate_ns_entrypoint, my search started.

Is there anything that makes the check for tegra and imx8mm unneeded? Or are they both broken and should better use plat_sdei_validate_entry_point from plat/arm/common/arm_common.c?

Thanks, Jan