Question about SMC filtering in smc_user.cpp on ARM64

--===============1621147031734603541==
Content-Type: multipart/alternative; boundary="00000000000084b1dc063aa8ea49"

--00000000000084b1dc063aa8ea49
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello all,

I'm currently working on integrating OP-TEE support on the ARM64
architecture within the L4Re framework, specifically focusing on
cryptographic operations such as encryption and decryption.

While reviewing the implementation, I noticed that in
fiasco/src/kern/arm/smc_user.cpp, non-fast SMC calls are explicitly
filtered out with the following check:

// only allow fast callsif (!(r0 & 0x80000000))
  return commit_result(-L4_err::ENosys);

I'm trying to understand the rationale behind this design decision.
Was it primarily driven by real-time performance requirements, or are there
other considerations=EF=BC=9F

Additionally, as OP-TEE often uses *yielding calls* for certain operations,
do you think it would be appropriate for us to consider extending the
kernel to support such calls?

We would appreciate any insights or recommendations you can provide.

Best regards,

--00000000000084b1dc063aa8ea49
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><p>Hello all,</p>
<p>I&#39;m currently working on integrating OP-TEE support on the ARM64 arc=
hitecture within the L4Re framework, specifically focusing on cryptographic=
 operations such as encryption and decryption.</p>
<p>While reviewing the implementation, I noticed that in <code>fiasco/src/k=
ern/arm/smc_user.cpp</code>, non-fast SMC calls are explicitly filtered out=
 with the following check:</p><pre class=3D"gmail-overflow-visible!"><div c=
lass=3D"gmail-contain-inline-size gmail-rounded-2xl gmail-relative gmail-bg=
-token-sidebar-surface-primary"><div class=3D"gmail-overflow-y-auto gmail-p=
-4" dir=3D"ltr"><code class=3D"gmail-whitespace-pre! gmail-language-cpp"><s=
pan class=3D"gmail-hljs-comment">// only allow fast calls</span>
<span class=3D"gmail-hljs-keyword">if</span> (!(r0 &amp; <span class=3D"gma=
il-hljs-number">0x80000000</span>))
  <span class=3D"gmail-hljs-keyword">return</span> <span class=3D"gmail-hlj=
s-built_in">commit_result</span>(-L4_err::ENosys);
</code></div></div></pre>
<p>I&#39;m trying to understand the rationale behind this design decision.<=
br>Was it primarily driven by real-time performance requirements, or are th=
ere other considerations=EF=BC=9F</p>
<p>Additionally, as OP-TEE often uses <strong>yielding calls</strong> for c=
ertain operations, do you think it would be appropriate for us to consider =
extending the kernel to support such calls?</p>
<p>We would appreciate any insights or recommendations you can provide.</p>
<p>Best regards,</p></div>

--00000000000084b1dc063aa8ea49--

--===============1621147031734603541==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
l4-hackers mailing list -- [email protected]
To unsubscribe send an email to [email protected]

--===============1621147031734603541==--