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
_______________________________________________
Devel mailing list -- devel@sel4.systems
To unsubscribe send an email to devel-leave@sel4.systems
