8 ms·
Any sandboxing adds a performance overhead. There is no free lunch in Operating Systems.
by aey 7y ago
Any sandboxing adds a performance overhead. There is no free lunch in Operating Systems.
- pjmlp 7y agoA tiny performance overhead is worthwhile in name of security. For example, I don't remember the last time I cared about disabling bounds checking, even in C++ code (VC++ allows to keep it on).
- rurban 7y agoTell that the various libc maintainers. They are blocking the C11 Annex K (safe bounds checks) for over a decade now. And talking about performance With good compilers my secure memcpy_s is actually faster than the glibc or BSD libc memcpy, with compile-time constexpr.
- pjmlp 7y agoI would blame ISO C, by making Annex K optional, and not caring to improve C's safety in general.
- aey 7y agoI am quite happy with rust these days. But it still lacks great ‘no allocation’ libraries.
- rurban 7y agoThen you are illusional. None of their safety guarantees are real. Memory, type, concurrency, none. But talking to them fall on deaf ears. Its called hype driven development and very popular amongst HN folks. There exist plenty of real safe languages though.
- monocasa 7y agoThe whole point of BPF is that you can't run this code in a separate context _and_ have the code work. The original use case was packet filtering in interrupts because waiting for user space took too long.
- pjmlp 7y agoIf I remember correctly Intel has implemented a user space TCP/IP stack exactly for that.
- monocasa 7y agoWhich doesn't work if you want to still share an adapter across multiple applications.
- vardump 7y agoI don't see any reason why it can't br made to work between multiple applications while being still faster than traditional kernel based stacks.
- monocasa 7y agoThe whole point of DPDK is to avoid the context switches by dedicating the adapter to a single application, and letting the application take over management. Once you have multiplexing, you're right back to where you started. There has been a secure multiplexing scheme based on packet buffers... the Berkeley Packet Filter (BPF), ie. what this paper is talking about as prior art.
- vardump 7y agoNo, you can simply have memory mapped ring buffers between processes and all of the stuff not required for the specific application cut away. You don't need to have any more context switches that way. No need to have a traditional socket API while still being able to do access it from multiple applications. I have no interest to create such beast, but I'd be truly shocked if it couldn't at least beat a generic kernel based stack. It'll lose some performance compared to the single application approach, but there might still be a niche for this kind of way. Sure, you'll need to copy memory, but the data should be almost always in L3 cache anyways.
- aey 7y agoBpf can handle 60 million packets per second, adding a user/kernel context switch will kill that by a factor of 1000x. So while your code may not care about it, there are definitely low latency applications where milliseconds equate to dollars.
- pjmlp 7y agoSome high integrity OSes do that full in user space, while running Linux on the side as it isn't certified for such scenarios.