4 ms·
Sorry, I responded too quickly to this comment: >- Libraries often CAN'T be written in a separate language without an additional effort -- and often writing wi
by catern 5y ago
Sorry, I responded too quickly to this comment:
>- Libraries often CAN'T be written in a separate language without an additional effort -- and often writing with interop in mind means you have to give up nice features like C++ STL containers
And I said something that wasn't quite right.
What I should have said is: Yes, writing a language-independent library can be harder, because you need to use a language-independent type system to describe the signature of the library. But it's harder still to write a standalone process, because protocol schemas are even less capable than language-independent type systems. And no, you don't need to avoid STL or anything.
>Re "Software fault isolation", ... you have manually serialize/deserialize messages
No you don't. For further reference, also look at the other library privilege-separation techniques I linked.
>are we talking about production languages which people write programs on
Yes. Such as C.
- theamk 5y ago> No you don't. For further reference, also look at the other library privilege-separation techniques I linked. > Yes. Such as C. Am I missing something? Your page lists the following privilege separation links: - Google's SFI paper: that only works in NaCL environments, and does not support "regular" C libraries - Wikipedia link to capabilities - no mention of C there, only Java and C# - Stack inspection - trivially bypassed in C - "Capability-safe architectures such as CHERI" - does not apply to common x86 servers. - "Multics-style "call gates"" - this is Multix specific, no such facilities exists in modern OSes So, if I have a modern app written in C or Python, which runs on regular Linux machine, and let's say there is a library which keeps running out of memory and crashing - what are my options? It looks like none of the links you mentioned apply.
- catern 5y agoUse NaCL or other SFI techniques. It doesn't require any kind of serialization/deserialization code, contrary to your suggestion. Here's the original SFI paper, maybe it's more approachable? https://cs155.stanford.edu/papers/sfi.pdf https://cs155.stanford.edu/papers/sfi.pdf
- theamk 5y agoI feel like you re not hearing my question -- I asked, "I have a modern app written in C or Python,[...] what are my options" and you are telling me to use NaCl, with last stable release in 2015. Even if NaCl was a good option (it was not), it is still discontinued. So let me ask again, are there any modern options for library isolation, something I can actually download and link to a C program? Something with github page I can visit and download the code, and a community that can support/answer questions? And if such thing exists, is this easier to use than your favorite IPC system? ----- Re NaCl: NaCL definitely requires some kind kind of serialization/deserialization code. The paper [0] is pretty clear that NaCl-isolated code lives in a separate process (see Figure 1, and section 2) and can only communicate over IMC, which uses "datagrams consisting of untyped byte arrays along with optional NaCl Resource Descriptors”. And you need serialization to send over untyped byte arrays. Moreover, at the end of section 2, the paper says: "It is not appropriate for modules requiring process creation, direct file system access, or unrestricted access to the network"... which rules out a lot of the interesting libraries. [0] https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/34913.pdf https://static.googleusercontent.com/media/research.google.c...