Hacker News Reader

> It would permanently have assigned its own segment of the global system address space

We’ve been moving away from this for security reasons with ASLR and position independent executables.

Fixed targets are dangerous for security reasons.

In a clean room OS you can avoid unsafe languages

Sounds cool until you think that you have to maintain this after new things are installed, removed and upgraded. ASLR is around for a reason, having everything statically fixed may bring security concerns.

And, how do you run multiple programs out of the same binary?

Running multiple instances: launch+fork with copy-on-write semantics?

Re: ASLR, yeah I think you would lose most of that mitigation. Would it be worth it to make launching even the biggest programs instantaneous? The usability upside could be something amazing; maybe some other security mitigations could take the place of ASLR.

Security mitigations given everything you can run has a fixed address sounds cool, but wouldn't the copy-on-write semantics kind of break that? I guess you might still be able to do something though.

Building ROP chains would so insanely easy; everybody doing binary exploitation would be much happier with this memory layout.

Mostly you're describing the macOS shared cache.

For individual applications there are many reasons that isn't reasonable (performance, security, etc).

But the perf gains you're asking for are mostly supported by the shared cache. The vast majority of launch time for an application is not the dynamic linker. It's the actual "load from disk" for the text and resources, then a pile of init logic.

Yeah, agree: the really big gain would come from moving init logic from load time to install time.

I'm not sure what you mean here - you can't move application launch logic to install time, it's inherently a launch time process - loading resources into memory, setting up runtime data structures, etc fundamentally requires time.

Now plenty of apps have unnecessarily large start up times, but those apps can largely be improved without just doing more work at install time - it's simply that a lot of devs don't care. There's a lot of "if it's not being measured, it's not being improved" for launch time for many - most? - projects and companies that means launch time is just slow for no reason.

you can't move application launch logic to install time, it's inherently a launch time process - loading resources into memory, setting up runtime data structures, etc

That is exactly what I want to do. Imagine your system had the full 64 bit address space populated with RAM. You launch every installed application simultaneously and let them run thru init to the point where they are ready for user interaction. Then suspend the whole system to disk. Thats what I want the "applications installed" state to look like.

In actual use you have limited RAM and launch applications one at a time. At launch time it is un-suspending the already initialized application. It has its own reserved virtual memory addresses so no need to reallocate new memory and no conflict with other running applications.

Emacs used to do something like this (maybe still does?) but in a very hacky way. I'd like it to be how the whole OS works.

Smalltalk images are somewhat similar: the whole machine state is persisted.