Compartment entry points with primitive arguments

[0152la]

Can now specify functions to behave as entry points in compartments, and can now pass (up to 3) primitive variables as arguments to those compartments. No pointer support at this time.

• Add one test to check two int arguments are correctly passed; more to follow
• A bit of tests folder cleanup

This is some initial progress, as there are a few things to clean up, but I think it's worthwhile to get some design feedback at this stage, and it serves as a decently sized intermediate PR. What is left to do:

• Better describe compartment entry points. I am thinking of a JSON or TOML file, or perhaps some CSV-like self-implemented system.
• Clean up the compartment call information from the two manager test scripts - ideally this would be contained in the above config file.
• Try to make argument passing work for main functions at least in the next stage, then maybe full blown pointers.

[ltratt]

@jacobbramley Are you willing to have a look at this too? At the very least you'll do much better at the assembly bits than I will!

[ltratt]

@0152la I think I'm missing too much context here, and you might need to give me the "for dummies" explanation! For example, who determines how many parameters are the correct number? Does the callee check that precisely the right number were passed or ... ?

[0152la]

@0152la I think I'm missing too much context here, and you might need to give me the "for dummies" explanation! For example, who determines how many parameters are the correct number? Does the callee check that precisely the right number were passed or ... ?

There aren't really any checks in the code as is; the number of passed parameters are in the manager [1]. I plan on putting this in a sort of compartment configuration file to be read by the manager when creating the compartment so it can be lifted at runtime from there, and checked against on call. In that case, we'd say the compartment writer would provide this additional configuration, which would indeed have to be checked by the callee (or perhaps I could integrate this check in compartment.c...).

Are there any more specific questions, or should I also give some more generic overview?

[1] https://github.com/capablevms/CHERI-ELF-comp/pull/6/files#diff-6e0cbcab5be8419f8d8accdd49cf5e8096fefb3f0f6f3105b8cb95662ba16347R25

[ltratt]

Are there any more specific questions, or should I also give some more generic overview?

Starting generic would certainly help me :)

[0152la]

Hmm. There's two things here that bleed into one another - what the end goal is, and what is implemented in this PR. I'll try to distinguish between them.

The goal is to define entry points in compartments, such that those functions can be called by other compartments (or the manager). Who defines these entry points is not finalized - at the moment I just hard code them in the testing manager scripts, but the next step will be to read a compartment configuration file which contains this information to be read by the manager.

Probably the central point in this PR is calling functions in compartments (main via comp_exec, then the comp_exec_in assembly stub. We pass parameters in registers, for which the procedure call standard (this is some document I can find the link for if needed) allots us 6 registers (I only use 3 for simplicity right now, but it's not hard to extend, just extra assembly in comp_exec_in). Another limitation, as discussed, is that we currently don't handle pointers, just raw primitives (need to add more tests to show this).

So now the question is how do we pack these arguments that we want passed? Well, could have a function with 6 parameters, representing these maximum 6 registers. I believe the Android example does that. I chose to pack them into a void** argument to comp_exec, and this seems to work with two levels of indirection. I think the API looks cleaner, but the manager needs to put in some more legwork to cast things and clean up.

So I think right now the question is if this design looks reasonable, at least for the one test (plus the few more I have in my head to add shortly to this PR), or if there is a better type-agnostic design we can choose. Or even a better way of passing arguments. Using only registers is rather constraining, but possibly sufficient for our purposes?

[0152la]

I've added a High-level idea to the readme to try and explain the overall functionality of the library, as we discussed earlier today. If you still think it's too lacklustre, I have some diagrams (primarily made for the meeting tomorrow) that I can fit in; we can discuss details after tomorrow's meeting.

[ltratt]

That is very helpful -- thanks!

Please squash.

[0152la]

Squashed.

[ltratt]

bors r+

[bors[bot]]

Build succeeded!

The publicly hosted instance of bors-ng is deprecated and will go away soon.

If you want to self-host your own instance, instructions are here. For more help, visit the forum.

If you want to switch to GitHub's built-in merge queue, visit their help page.

• buildbot/ci-builder