Does Aarch64 LDTR behave differently in secure vs non-secure?

I am not asking if I can get out of NS. Allow me to provide a use-case, which to me suggests that LDTR is broken:

Secure services wishes to provide an API that provides some information to are request that originates at NS-EL0. Because the returned information is buffer sized, the API requires that NS-EL0 provides a pointer to the file resting place of the result. Example: User requests that a message be decoded. The C++ API might be:

void DecryptMessage( const string& encrypted_message, string& decrypted_message, const credentials& requestor_id);

This passes from NS-EL0 to NS-EL1 to EL3 to S-EL1 or possibly S-EL0 where the operation is validated (perhaps using fingerprint or facial identification hardware) prior to decode. Now I am operating in Secure mode, but I wish to verify that the pointers for the message buffers are legal NS-EL0 pointers. Using LDTR and STDR seems like the correct way to validate operations. This would avoid having to manual interpret the MMU mapping (which could be in any of 3 different MMU table translation formats). However, if the pointers are interpreted in the context of S-EL0, then I might be using the wrong MMU translation and be pointing to secure memory.

In other words, how would I validate a pointer (address) from NS-EL0 when operating in Secure world or ELn (n>=1)? I infer this was part of the intended purpose of these instructions. v8-M has similar instructions; although, I think they are closer to what I am looking for.

I am not asking if I can get out of NS. Allow me to provide a use-case, which to me suggests that LDTR is broken:

Secure services wishes to provide an API that provides some information to are request that originates at NS-EL0. Because the returned information is buffer sized, the API requires that NS-EL0 provides a pointer to the file resting place of the result. Example: User requests that a message be decoded. The C++ API might be:

void DecryptMessage( const string& encrypted_message, string& decrypted_message, const credentials& requestor_id);

This passes from NS-EL0 to NS-EL1 to EL3 to S-EL1 or possibly S-EL0 where the operation is validated (perhaps using fingerprint or facial identification hardware) prior to decode. Now I am operating in Secure mode, but I wish to verify that the pointers for the message buffers are legal NS-EL0 pointers. Using LDTR and STDR seems like the correct way to validate operations. This would avoid having to manual interpret the MMU mapping (which could be in any of 3 different MMU table translation formats). However, if the pointers are interpreted in the context of S-EL0, then I might be using the wrong MMU translation and be pointing to secure memory.

In other words, how would I validate a pointer (address) from NS-EL0 when operating in Secure world or ELn (n>=1)? I infer this was part of the intended purpose of these instructions. v8-M has similar instructions; although, I think they are closer to what I am looking for.

LDRT is a pre-trustzone instruction, so it is clear it has no notion of secure/non-secure in the first place.
Anyway, I see no reason to "validate" the pointer as there should be no common memory between secure and non-secure world despite a "small" shared memory area. It is IMHO a bad design if secure world has full access to the normal worlds memory.
So even if EL0 provides a pointer to some buffer, it shall be either one in the shared memory or EL1 does a copy from user land to the shared memory and back.

The secure world can easily check if the provided pointer is within the range of the shared memory (given it has the same address mapping).