Clear caller ID on sancus_disable

[jovanbulck]

Problem. The unprotect instruction currently does not clear caller ID, which may enable an attacker controlling the continuation argument to spoof one caller authentication in multithreaded programs, without interrupting SMs:

• thread 1: unprotected -> reader SM -> sensor SM (get data entry) -> unprotected (logging function)
• thread 2: unprotected -> sensor SM (disable entry) -> unprotected (continuation) -> reader SM

An attacker controlling the unprotected domain suspends thread1 on the unprotected sensor SM outcall. Next, the sensor SM is disabled in thread 2 and execution continues at an unprotected continuation point (with the valid callerID of the sensor SM). At this point, the attacker simply "returns" into the reader SM, passing arbitrary spoofed return values in CPU registers. The reader SM now cannot rely anymore on sancus_get_caller_id to authenticate this return call.

Solution. After execution of the unprotect instruction, the ID of the previously executing module should be zero.

[jovanbulck]

On the other hand, a multithreaded SM in the above scenario should of course only disable itself after it has finished all its internal execution threads.

The ID should still be cleared, however, since the continuation point could possibly be the entry point of another SM. In such a case, the continuation SM could be tricked into believing the call originated from a valid (still loaded) SM...