[rlpb]

> each being allocated their own parsing process

That just punts the vulnerable code elsewhere. A kernel bug could leak memory across processes. And the kernel is also written in C, so you aren't getting protection from a "better" language either.

[simias]

That's assuming that the likelihood of such a bug in the kernel code is the same as a bug in an HTML parser. And also that this bug would go unnoticed for months. The fact that both are written in C doesn't make them equal.

[tgragnato]

absolutely true

[icebraining]

Thing is, with the single model process, a kernel bug could also leak memory between customers. And in fact, it's much more likely, since for it they're all in the same security context. So it's not punting the code, it's reducing the attack surface.

[rlpb]

> And in fact, it's much more likely, since for it they're all in the same security context.

I disagree. I think it's much less likely, because the kernel doesn't usually get involved in the process' memory once it is allocated.

Sure, it maps the virtual memory about to physical memory as needed, but bugs there is likely to cause severe corruption resulting in an immediate crash. The kernel doesn't go low level enough for it to be likely to result in messing with a process such that the single process continues to work but also leaks across the process-internal customer boundary that the kernel cannot see. That would require a level of surgical precision I don't think is likely in a bug.

To be clear, I'm not saying that you shouldn't use per-customer processes. The kernel has more eyes and is less likely to be vulnerable in this way. Just that from an analytical perspective, you are really just moving the problem elsewhere, rather than solving it.