freenode/#mezzano - IRC Chatlog
Search
19:10:35
Serach
I'm curious how this all works. How do you run CL code without a compiler at runtime?
19:11:13
Serach
Is it a statically-typed subset that it completely compiled into native code, requiring no runtime?
19:15:12
antoszka
Serach: It very much depends on the implementation behind. Since this is #mezzano, I don't really know how the mezzano CL is organised in this respect;
19:15:45
antoszka
Serach: But most CL's could theoretically run without a *compiler* when there's no code-generation or eval in place.
19:17:19
Serach
I assume the userspace is running on a Lisp implementation, whereas the kernel is just native code, then?
19:47:37
froggey
there's not really a user/kernel distinction. the supervisor (kernel equivalent) is written in a subset of common lisp that requires no runtime support along critical paths, but is otherwise normal
19:51:37
antoszka
Serach: I don't think there ever was a Lisp OS that had a clear user/kernel space separation (the way modern Unix NT do).
19:52:05
antoszka
Serach: This would be contrary to the ideas that permeate lisp oses (full accessibility to every layer *down* from the REPL).
20:06:41
froggey
it's prboom compiled with a C compiler that produces common lisp instead of assembly/machine code
20:10:31
froggey
right. the heap, C stack, and data section are all stored in a single large byte vector
20:12:08
froggey
interesting bit is here: https://github.com/froggey/iota-llvm/tree/master/tools/iota
20:14:32
Serach
I didn't realize that Mezzano was not just an operating system written in Lisp, but a departure from the normal design of operating systems in general.
20:17:32
Serach
I have a question, though. What's to stop someone from modifying cached compiled code on the disk to run malicious code in Ring 0? Does the OS not cache code to the disk?
20:20:03
froggey
compiled code isn't really cached. it gets compiled and the system doesn't refer to the original source code after that
20:20:20
froggey
it does get saved to disk, and it would be possible for something to modify it on disk
20:21:02
froggey
but that seems like a physical security issue to me, solved with disk encryption or similar
20:27:36
Serach
Perhaps. It does seem like it makes malware much easier to write, though. If you can get a piece of arbitrary native code to run, you're all the way there. And it makes it trivial for someone with physical access to a machine to completely control it. Schools and libraries would need to have a really locked-down setup.
20:33:02
froggey
sure, the security model assumes that the user owns/is responsible the machine. there's a single user and the user is permitted to do whatever
20:37:09
Serach
Hm... I guess that a neat advantage of this whole setup is that Mezzano software could theoretically run easily on other operating systems.
20:41:07
Serach
A large part of it is really about packaging, I think. You can distribute Lisp software in source form, or as an executable that contains bytecode, along with the entire implementation. It would be neat to have something like JAR files that can run anywhere, provided that the user has the runtime installed.
20:41:46
Serach
If there's something exactly like that and I'm just being stupid, forgive me. I'm still pretty new to Lisp.