4 ms·

> But I DO think it's difficult to design an IPC mechanism that everyone is happy with. Some people want only synchronous IPC ... Every form of IPC can be impl

> But I DO think it's difficult to design an IPC mechanism that everyone is happy with. Some people want only synchronous IPC ... Every form of IPC can be implemented on top of asynchronous message passing. Interface is not the problem. The problem is high performance designs with all the batching, memory mapped buffers, no syscalls, etc.

naasking 7y ago
> Every form of IPC can be implemented on top of asynchronous message passing Sure, if you want to introduce inherent DoS vulnerabilities into your IPC subsystem, not to mention slow down IPC so much that it's practically unusable. Many early microkernels were asynchronous, and synchronous microkernels like L4 beat them easily every time. Furthermore, synchronous IPC can be made immune to DoS which is inherent to async IPC: https://www.researchgate.net/publication/4015956_Vulnerabilities_in_synchronous_IPC_designs https://www.researchgate.net/publication/4015956_Vulnerabili...
- zzzcpan 7y ago
  > Sure, if you want to introduce inherent DoS vulnerabilities into your IPC subsystem, not to mention slow down IPC so much that it's practically unusable. This is nonsense. There could be DoS vulnerabilities in implementations, but they are not inherent to async message passing.
  - naasking 7y ago
    Yes they are. Who owns the buffers needed to store the async messages? 1. If they're booked to the receiver, then clients can easily DoS receivers by flooding them with message. 2. If they're booked to the sender, then receivers can easily DoS senders by blocking indefinitely. 3. If they're booked to the kernel (which is most common for true async message passing, unfortunately), then senders or receivers can DoS the whole system by the above two mechanisms. And that's only the most basic analysis. I suggest you read the paper I linked and its references if you want a more in-depth analysis of IPC vulnerabilities and performance properties.
    - zzzcpan 7y ago
      You are over simplifying it and dropping too many important details so that it ceases to be a real system and becomes some weird system susceptible to DoS. In high performance scenario it would be more like this: process shares fixed ring-like buffers with the kernel where it can put messages, messages it can't put there it either accumulates locally until it can or just drops, there would be some kind of polling or event notification mechanism to know when it can put and get more messages into and from shared buffers. P.S. I can't access the paper, but presumably they are making the same faulty assumptions if they claim the same things you did.
      - naasking 7y ago
        No, you are oversimpifying by assuming mutual trust between processes, which is not a suitable assumption for a system-level message passing system. > process shares fixed ring-like buffers with the kernel where it can put messages I am making a claim like "Turing machines can't solve the Halting problem", and you are saying, "If you put a limit the number of computation steps, then the Halting problem is decidable". But such a system is no longer a Turing machine. What you are describing is not asynchronous IPC. With async IPC, you ought to be able to send a message at any time without blocking. That's what async IPC means. If you must sometimes block or throttle before you can successfully send a message, even if only in principle, then it's no longer async IPC. It is instead a mixed sync/async system, which invariably becomes necessary in order to address the inherent limitations of async IPC. > messages it can't put there it either accumulates locally until it can or just drops So DoS against the sender, like I said. Try assuming a less liberal threat model and see how far async IPC takes you.
        zzzcpan 7y ago
        There is no assumption of mutual trust between processes, and there is nothing synchronous about it, you still don't know whether any of the messages reached their destinations. This is just backpressure, asynchronously propagated (or synchronously, depending on your interpretation of it). And still no DoS, it's completely up to the application to decide what to do with the messages it generates too fast.
- Matthias247 7y ago
  Haven’t even some L4 designs moved to async IPC for performance reasons? I remember having read about OKL4/Genode being async. Fuchsia certainly is async, but that’s not if L4 family.
  - naasking 7y ago
    > Haven’t even some L4 designs moved to async IPC for performance reasons? I know only of async notifications, which I believe require no allocation of storage and so don't open up DoS opportunities.

naasking 7y ago

> Every form of IPC can be implemented on top of asynchronous message passing Sure, if you want to introduce inherent DoS vulnerabilities into your IPC subsystem, not to mention slow down IPC so much that it's practically unusable. Many early microkernels were asynchronous, and synchronous microkernels like L4 beat them easily every time. Furthermore, synchronous IPC can be made immune to DoS which is inherent to async IPC: https://www.researchgate.net/publication/4015956_Vulnerabilities_in_synchronous_IPC_designs https://www.researchgate.net/publication/4015956_Vulnerabili...

zzzcpan 7y ago
> Sure, if you want to introduce inherent DoS vulnerabilities into your IPC subsystem, not to mention slow down IPC so much that it's practically unusable. This is nonsense. There could be DoS vulnerabilities in implementations, but they are not inherent to async message passing.
- naasking 7y ago
  Yes they are. Who owns the buffers needed to store the async messages? 1. If they're booked to the receiver, then clients can easily DoS receivers by flooding them with message. 2. If they're booked to the sender, then receivers can easily DoS senders by blocking indefinitely. 3. If they're booked to the kernel (which is most common for true async message passing, unfortunately), then senders or receivers can DoS the whole system by the above two mechanisms. And that's only the most basic analysis. I suggest you read the paper I linked and its references if you want a more in-depth analysis of IPC vulnerabilities and performance properties.
  - zzzcpan 7y ago
    You are over simplifying it and dropping too many important details so that it ceases to be a real system and becomes some weird system susceptible to DoS. In high performance scenario it would be more like this: process shares fixed ring-like buffers with the kernel where it can put messages, messages it can't put there it either accumulates locally until it can or just drops, there would be some kind of polling or event notification mechanism to know when it can put and get more messages into and from shared buffers. P.S. I can't access the paper, but presumably they are making the same faulty assumptions if they claim the same things you did.
    - naasking 7y ago
      No, you are oversimpifying by assuming mutual trust between processes, which is not a suitable assumption for a system-level message passing system. > process shares fixed ring-like buffers with the kernel where it can put messages I am making a claim like "Turing machines can't solve the Halting problem", and you are saying, "If you put a limit the number of computation steps, then the Halting problem is decidable". But such a system is no longer a Turing machine. What you are describing is not asynchronous IPC. With async IPC, you ought to be able to send a message at any time without blocking. That's what async IPC means. If you must sometimes block or throttle before you can successfully send a message, even if only in principle, then it's no longer async IPC. It is instead a mixed sync/async system, which invariably becomes necessary in order to address the inherent limitations of async IPC. > messages it can't put there it either accumulates locally until it can or just drops So DoS against the sender, like I said. Try assuming a less liberal threat model and see how far async IPC takes you.
      - zzzcpan 7y ago
        There is no assumption of mutual trust between processes, and there is nothing synchronous about it, you still don't know whether any of the messages reached their destinations. This is just backpressure, asynchronously propagated (or synchronously, depending on your interpretation of it). And still no DoS, it's completely up to the application to decide what to do with the messages it generates too fast.
Matthias247 7y ago
Haven’t even some L4 designs moved to async IPC for performance reasons? I remember having read about OKL4/Genode being async. Fuchsia certainly is async, but that’s not if L4 family.
- naasking 7y ago
  > Haven’t even some L4 designs moved to async IPC for performance reasons? I know only of async notifications, which I believe require no allocation of storage and so don't open up DoS opportunities.