You’re right, I might have been a bit too hasty in this and not properly looked at the distinction between call/reply and send/wait. Will have another look and confirm.
Cheers, Gerwin
On 17 Sep 2022, at 10:49 am, Indan Zupancic indan@nul.nu wrote:
Hello,
Just replying to what would be, for me, unexpected behaviour:
On 2022-09-14 11:54, Gerwin Klein wrote:
On 13 Sep 2022, at 7:01 pm, Demi Marie Obenour wrote: It is. An PPC callee is allowed to block for as long as it desires, and doing so will block the caller too. There is no way (that I am aware of) to interrupt this wait. Therefore, the callee can perform a trivial denial-of-service attack on the caller.
This is correct in the sense that an IPC call implies trusting the invoked party to return to you. There is a mechanism (bound notifications) that allows you to interrupt that wait,
I don't think IPC calls are interruptible by bound notifications. That would be very unexpected behaviour, and if true, should be made very clear in the manual. Now it says:
"An important variant is the Call operation, which consists of a standard Send operation atomically followed by a variant of Receive which waits for a Reply. A reply message is always delivered via a special resource instead of using the standard IPC mechanism;"
"A reply capability points directly to the caller thread and once the call has been performed is completely unrelated to the original Endpoint."
"When a Notification is bound to a TCB, signals to that notification object will be delivered even if the thread is receiving from an IPC endpoint."
All this implies to me that calls will not be interrupted by signals.
When looking at the source it also seems notifications don't interrupt calls:
Threads making a call are put into ThreadState_BlockedOnReply and sendSignal() handles that case with:
} else { /* In particular, this path is taken when a thread * is waiting on a reply cap since BlockedOnReply * would also trigger this path. I.e, a thread * with a bound notification will not be awakened * by signals on that bound notification if it is * in the middle of an seL4_Call. */ ntfn_set_active(ntfnPtr, badge); }From a quick look at the source I think the only ways to interrupt a call in progress are replying, seL4_CNode_CancelBadgedSends(), destroying related resources or suspending the caller.
To be clear, I think not being able to interrupt calls with signals is the right behaviour and anything else would cause hard-to-find bugs.
Greetings,
Indan