First draft

[0152la]

Includes work in progress of minimal required ELF loader, with basic memory management, and compartmentalization manager.

The main components are as follows:

• compartment.c - source code for internal compartment functionality, including loading a compartment, mapping, executing, and others. Essentially an ELF loader, targetting static ELF executables (currently hard-coded for executables pre-compiled to the loaded at address 0x1000000 in memory);
• mem_mng.c - utilities to do with memory management of compartments. We intercept calls to malloc, realloc, and free in the loaded compartments and redirect them to corresponding functions in this file, to perform memory operations outside of the compartment;
• manager.c - overarching wrapper, holding information about the execution state, managing compartments, and other needed miscellaneous stuff.

In addition, a number of tests are provided to assess functionality. The most current ones are lua_simple.c, which performs some basic lua operations, and hello_world_comps.c, which creates a compartment from a compiled variant of the aforementioned executable and attempts to execute it.

As this is a work-in-progress, things are broken, and very in flux.

[0152la]

I'll leave this as a draft PR, as buildbot/bors stuff still needs to be done. Otherwise, questions/comments on the code very welcome.

[ltratt]

As I'm sure you expected, I don't pretend to have fully understood this yet! But I get many of the major ideas, and overall it looks like a really promising start!

A question that immediately sprung to mind: what would it mean to create a compartment "mid stream" i.e. after the program has started running? In other words, imagine the process has been running for a while, and you want to create a new DDC compartment: would that be the rough equivalent of fork or would you definitely need to go through the full ELF initialisation stuff and so on? [I'm not expecting a solution for this in this PR: but it's a question that might be worth chewing over.]

[0152la]

A question that immediately sprung to mind: what would it mean to create a compartment "mid stream" i.e. after the program has started running? In other words, imagine the process has been running for a while, and you want to create a new DDC compartment: would that be the rough equivalent of fork or would you definitely need to go through the full ELF initialisation stuff and so on? [I'm not expecting a solution for this in this PR: but it's a question that might be worth chewing over.]

Just to clarify some things, when you say "the process", I will understand it as being the combination of the loader and its underlying compartments (as they are all within a single process on the OS side, at least at the moment). Creating a new compartment should be a call to comp_from_elf from within the manager context. I believe "the full ELF initialisation stuff" means what's happening in this function. This needs to be done for every single new compartment (i.e., every new static binary we want to load) in the current design. It might be possible to have separate processes for each compartment, if that's what you suggest by fork, but I don't think we need that for parallelization.

[ltratt]

I didn't phrase my question very well -- sorry! I'm partly thinking "what happens if, after running for a while, you want to run another computation in a compartment?" I'm wondering if you can "setup" a new compartment without having to go through main every time.

[0152la]

You need to load the compartment once in memory, which is done via comp_from_elf. Once it's in memory, it should be possible to execute it as many times as desired, via comp_exec. I haven't gotten to the point yet where we call specific functions with specific arguments passed to them, but I see no technical reason why this wouldn't be possible. But the compartment needs to be loaded into memory a single time, and then should be able to be reused as many times as desired, until it is explicitly unloaded (which is not fully implemented yet).

[ltratt]

Ah, that's an interesting point -- that does sound plausible.

[0152la]

@jacobbramley Do you want to spare some time looking at this PR in its current state (it's draft for now as I haven't done the bors stuff required to be able to merge it), or do you prefer to wait until the code becomes more stable?

[0152la]

Ok, seems the comments I wrote end of last week weren't actually submitted, and were marked pending. They should be visible now. Sorry for the confusion.

[ltratt]

I've resolved a few of my comments: a few are still open. I'll leave you and @jacobbramley to discuss your various comments :)

[0152la]

bors ping

[bors[bot]]

pong

[0152la]

bors try

[bors[bot]]

try

Build failed:

• buildbot/capablevms-test-script

[0152la]

bors try

[bors[bot]]

try

Build failed:

• buildbot/capablevms-test-script

[0152la]

bors try

[bors[bot]]

try

Build failed:

• buildbot/capablevms-test-script

[0152la]

bors try

[bors[bot]]

try

Build failed:

• buildbot/capablevms-test-script

[0152la]

bors try

[bors[bot]]

try

Build failed:

• buildbot/capablevms-test-script

[0152la]

bors try

[bors[bot]]

try

Build failed:

• buildbot/capablevms-test-script

[0152la]

bors try

[bors[bot]]

try

Build failed:

• buildbot/capablevms-test-script

[0152la]

bors try

[bors[bot]]

try

Build failed:

• buildbot/capablevms-test-script

[0152la]

bors try

[bors[bot]]

try

Build failed:

• buildbot/capablevms-test-script

[0152la]

bors try

[bors[bot]]

try

Build succeeded:

• buildbot/capablevms-test-script

[0152la]

Alright, bors is set up. Had a temporary issue that got fixed over the weekend.

[ltratt]

Are you asking for rereview or .. ?

[0152la]

I haven't changed any of the stuff that has already been reviewed, I guess I'm asking if there any any unresolved comments that need further attention, or if either you or @jacobbramley want to take more time with this PR.

[jacobbramley]

I don't have anything new. There are quite a few things that are for future use or investigation, but we can wait for #2, I'm sure :-)

[0152la]

Ready for review @ltratt .

[ltratt]

I've just noticed that this PR is 49KLoC, but I remember it being ~2KLoC at some point. Is my memory faulty?

[0152la]

No, I needed to add lua to it for the future. Although now that I think of it, I might be able to simplify it, and just include a patch and a submodule.

[ltratt]

Yes, I'd really much prefer we didn't slurp in the whole Lua code if at all possible!

[0152la]

bors try

[bors[bot]]

try

Build failed:

• buildbot/capablevms-test-script

[0152la]

bors try

[bors[bot]]

try

Build failed:

• buildbot/capablevms-test-script

[0152la]

bors try

[bors[bot]]

try

Build failed:

• buildbot/capablevms-test-script

[0152la]

bors try

[bors[bot]]

try

Build succeeded:

• buildbot/capablevms-test-script

[0152la]

Ready for review. Lua has been replaced with a submodule and the build system adjusted appropriately.

[ltratt]

Please squash.

[0152la]

Squashed.