4 ms·

In my dream world 64 bit OS, every program would be statically relocated at install time. It would permanently have assigned its own segment of the global syste

by dzdt 3y ago

In my dream world 64 bit OS, every program would be statically relocated at install time. It would permanently have assigned its own segment of the global system address space. Every library it depends on would also have a permanently assigned segment of the global address space. Also at install time the application would run all its initialization steps including GUI object allocation, with GUI object handles permanently assigned in their own segment of a global address space. The linked and initialized state of the application would be stored. Then launching the application would be more similar to a resume-from-suspend operation: memmap the pre-initialized state into its already reserved segment of address space and reactive the frozen gui objects. Probably I'm naive: I've never built any of this kind of low-level OS stuff. But I really do think there is room to re-envision some things which were decided in the 1970's based on constraints of 1970's hardware.

dietr1ch 3y ago
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?
- dzdt 3y ago
  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.
  - dietr1ch 3y ago
    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.
l33t233372 3y ago
> 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.
- wbl 3y ago
  In a clean room OS you can avoid unsafe languages
olliej 3y ago
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.
- dzdt 3y ago
  Yeah, agree: the really big gain would come from moving init logic from load time to install time.
  - olliej 3y ago
    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.
    - dzdt 3y ago
      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.
ivlad 3y ago
Building ROP chains would so insanely easy; everybody doing binary exploitation would be much happier with this memory layout.

by dzdt 3y ago

dietr1ch 3y ago

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?

dzdt 3y ago
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.
- dietr1ch 3y ago
  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.

l33t233372 3y ago

> 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.

wbl 3y ago
In a clean room OS you can avoid unsafe languages

olliej 3y ago

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.

dzdt 3y ago
Yeah, agree: the really big gain would come from moving init logic from load time to install time.
- olliej 3y ago
  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.
  - dzdt 3y ago
    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.

ivlad 3y ago

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