Difference between revisions of "Compel TODO"
| Line 18: | Line 18: | ||
For now the libcompel.a is built, so only static linkage is possible. Making it .so should not be a big deal, it mostly depends on the API rectification task (API should be extendable and backward compatible). | For now the libcompel.a is built, so only static linkage is possible. Making it .so should not be a big deal, it mostly depends on the API rectification task (API should be extendable and backward compatible). | ||
| − | * < | + | * <code>make compel/libcompel.so</code> works |
==== Save/Restore SAS in standalone mode ==== | ==== Save/Restore SAS in standalone mode ==== | ||
It's currently only handled by CRIU | It's currently only handled by CRIU | ||
Revision as of 14:20, 29 December 2016
Check and fix non-x86 arches
CRIU works with compel just fine, but standalone mode is verified by tests on x86 only.
Fix "root-only" obstacle
CRIU is root-only tool, so we've only checked compel to work when used by root-capable tasks. However, making it work from non-root user is possible, not that hard and makes perfect sense.
Tune the API
Right now we have some stuff that just got into compel/include/uapi/ when we moved the code around and should be hidden. Naming could probably be better too. Configuring the infection context is also FIXME-able.
Rectify parasite loading
For now the prepared parasite ELF should be converted into a C header file, then compiled with infection code, then libcompel can inject it into victim. Reorganizing the code so that it loads the ELF itself is tempting.
- Made C-header loading MUCH nicer with pre-generated macros.
Make .so version of the library
For now the libcompel.a is built, so only static linkage is possible. Making it .so should not be a big deal, it mostly depends on the API rectification task (API should be extendable and backward compatible).
make compel/libcompel.soworks
Save/Restore SAS in standalone mode
It's currently only handled by CRIU