Hacker News Reader

Comment by catnaroek | Hacker News Reader

> Instead, if your system is written in Lisp, then you can directly pass lisp objects from one lisp application to another lisp application, and there's no need to serialize/deserialize, to parse or otherwise mangle the data: you just have lisp objects and you can use them directly. You can pass closures (which enclose the lisp object data along with the lisp functions needed to process them).

So, if I understand correctly, the memory block in which a particular object is stored doesn't belong a priori to this or that process, but rather you can simply hand down objects to other processes? This is very cool! I've been thinking for quite a while that the very idea of memory protection is just a lame workaround to deal with the fact C is memory-unsafe.

View on HN

From what I can tell looking at the code, Mezzano doesn't have processes, just threads. There's no distinction between the kernel and user-space.

Whilst convenient, it isn't an unqualified good. Bugs in any part of the system have the potential to catastrophically break everything. It's also terrible for security. |Without the notion of a distinct kernel - or "unsafe" code that only privileged users can compile or load - there's nothing to stop user code reading or writing directly to/from IO ports or arbitrary memory locations.

Being able to pass closures isn't something that's particular to Lisp, nor does it require a lack of memory protection. It just requires that the calling convention can denote a closure as such, and can arrange for it to be invoked in the right security context - i.e. the one in which it was created.

Another issue with having a single global environment backing everything is that you can't easily experiment with changing built-in Lisp functionality without immediately crashing the system.

This sort of thing is probably perfectly fine for embedded systems, and "micro-service" VMs, though. The benefits may well outweigh the risks then. And of course it's great as a starting point for experimentation.

> From what I can tell looking at the code, Mezzano doesn't have processes, just threads.

I'd rather there were no distinction between processes and threads. It's artificial. I want to live in a world where processes cooperate to produce useful results for the user, rather than assume other processes are out there to corrupt their data. If there's any memory protection, I'd rather it be a compile-time, rather than runtime check.

> Bugs in any part of the system have the potential to catastrophically break everything. It's also terrible for security.

Proof-carrying code seems like a better solution than memory protection.

> Another issue with having a single global environment backing everything is that you can't easily experiment with changing built-in Lisp functionality without immediately crashing the system.

To be honest, I'm not so interested in “experimentation”. (I'm culturally not a Lisper. I like thinking and getting things right before I write code.) I just think concurrency would be a lot simpler if you could pass objects directly between programs written by different people.

This seems like a well-articulated point, written with a civil tone. Rather than downvoting, perhaps people could make a counter-argument? The approach of "thinking and getting things right" before writing code might not be common with this audience, but there are fields where it's the only way to work.

I think the idea of compile-time safety proofs is interesting. The number of runtime cycles spent on policy enforcement could be greatly reduced. Would it ever be possible, though, to derive such proofs for programs written in "unsafe" languages, or for arbitrary binaries?

An OS which only supports one language would be unlikely to be generally useful, although it might provide sufficiently compelling benefits for specialized use cases. I believe MirageOS represents an OCaml implementation of this idea, although it may in fact support other languages.

> It's also terrible for security.

The security angle is interesting.

The thing about independent processes is that we're relying on the OS to provide a wall around each process to limit it's impact by default. Maybe a better approach would to be include something like chroot/containerization for execution of closures within the language? Ie, if program 'A' receives data from program 'B', it can evaluate that data in a sandbox with limited permissions (IO limitations like no networking, or CPU resource limitations and time limits) and receive exceptions if the closure tries to exceed it's permissions. That could fit in pretty cleanly with Common Lisp's condition system.

A con of this though: you could argue that it really breaks encapsulation; it's bad enough when different parts of a large program become too closely coupled - allowing different applications to depend on the internal state of each other could be a nightmare.

Relevant links here:

https://news.ycombinator.com/item?id=12362583

I've really enjoyed your link-sharing lately. Thanks for spreading knowledge :)

No runtime analysis can simultaneously allow all intended sharing and prevent all unintended sharing. Best you can hope for is a static analysis that rejects programs that would share objects in unintended ways.

I'm not talking about automated runtime analysis per se. The type of permission setting I had in mind would be specified by the programmer and enforced by the runtime/OS.

Ah, okay, makes sense.

Well, if you're running on a typical processor than any process can use pointer arithmetic to access memory, so you still need some sort of low-level memory protection mechanism.

On some hypothetical Lisp/high-level-language processor, that needn't be the case, of course, but I honestly don't think we'll ever see something like that again.

> than any process can use pointer arithmetic to access memory,

The damage this can potentially cause can be prevented using proof-carrying code.

I'm not sure why you're being downvoted.

Store applications as byte code or source code and use a trusted JIT to generate machine code. With a system-wide garbage collector and bounds checking you would have a memory safe single address space operating system.

> I honestly don't think we'll ever see something like that again.

Why?

Probably fragility and security issues in that type of system.

One of earlier works combining high-security and functional programming was a security kernel for Scheme48:

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.37.4...

http://mumble.net/~jar/pubs/secureos/

That was the Scheme mathematically-verified in VLISP project:

https://en.wikipedia.org/wiki/PreScheme

There was also a mathematically-verified, Scheme CPU:

http://www.cs.indiana.edu/pub/techreports/TR544.pdf

I imagine combining even these three components into an integrated systems would provide a lot more security and availability than the average desktop. The simplicity of the CPU might also aid in producing a NonStop-like solution for five 9's availability.

Reply on news.ycombinator.com