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