Feature changed by: Michael Matz (matz2) Feature #320868, revision 2 Title: gcc multiverse support Requested by: Luis Rodriguez (mcgrof) + Partner organization: openSUSE.org Description: One of the task involved in FATE#315712 ("XEN: Use the PVOPS kernel") was to develop a solution to address dead-code concerns. This is being developed through a linker-table solution documented as part of a generic kernel-sandboxing strategy (http://kernelnewbies.org/KernelProjects/kernel-sandboxing) . This work is ongoing, and has broad uses outside of the scope of the Linux kernel. Long term, the Linux kernel solution may end up re-using some of the existing infrastructure to free __init code to free code when needed, and may extend this functionality to also alternatively do other things with region of unused code, one option for instance may be to make certain code not present to trigger page faults upon access. These solutions are very Linux specific and generalizing this may prove hard in other projects of interest to SUSE. In review with Alexander Graf, he has proposed an alternative mechanism which would be much more appropriate as a generic solution, this requires extending gcc. Support for this feature and public traction of this feature is being documented on the kernel newbies compiler-multiverse wiki (http://kernelnewbies.org/KernelProjects/compiler-multiverse) . gcc could be extended to generalize the binary patching technique used in the Linux kernel for use for any application. What this provides is variable optimized run time multiverse support. Technical feasibility Its known in theory this should technically be possible given that: * variable attributes exist, this would be used * functions can be cloned, even with special variable settings Example Let's consider the simple case of using a bool which only has two possible values: * true * false Code that would want to make use of this would annotate that the bool can be optimized for binary patching using a special attribute, for instance:

static __attribute__((multiverse)) bool some_value; int foo(void) { if (some_value) { do_a(); } else { do_b(); } } int main(int argc, char **argv) { if (argc > 1) some_value = true; gcc_runtime_optimize_variable(&some_value); }

In this example when gcc would see some_value has the multiverse annotation, it would clone the foo() function twice, for two different possible universes , one where some_val is true, and one where some_val is false. The references to the some_val locations in code are also stored for later use (generic some_val use, where some_val = true, some_val = false) in a special section to allow for run time patching. Applications get to hint during run time when a variable is deemed stable, this means that the variable value will not change for either: * a very long time * forever If an application, or the kernel, determines that a configuration variable is now deemed "stable", it can enable the application to put itself into an application specific safe state (for instance perhaps disallow concurrent threads, disable preemption, perhaps machine_stop() in the kernel). After this application specific safe-state call, a generic function would be called that would run time patch either the first few bytes of some generic functions or all invocations of the generic functions with the specialized variant for the current value of some_val. Benefits Benefits once this happens: * code executes and performs runs as efficienbtly as if some_val would have just been a const bool, or as if some_val would never had needed to be runtime determined * no register clobbering * no [id]cache pollution * ability to identify and compartmentalize dead-code * ability to decide how to handle dead-code at run time: * freeing unused code after variable stable state is reached * ability to enable debugging phase to ensure code that should not runs does not run, for instance by marking dead-code as not present Negative effects Expected negative effects to consider: * function cloning would increase the final size of a binary * due to size impact, use of this functionality should be limited Use Case: Potential uses Expected potential uses: * Linux's UP/SMP patching * Linux's pv-ops * Linux's alternative patching based on cpu features * QEMU's kvm_enabled(), xen_enabled(), etc * user space JIT with runtime cpu feature detection * anything that wants to optimize for cpu features * dpdk network filter features Business case (Partner benefit): - An evaluation of business impact is not yet done, this work is being - considered due to the parallels in gains accepted that is known to - exist for qemu as with the work that is being done to address dead-code - for Xen due to the switch to pvops to support Xen on Linux. A business - evaluation of impact of the gains of this can be assessed once tools - are written to help evaluate the amount of dead-code in a project at - run time. At least one public evaluation (https://www.internetsociety.org/sites/default/files/Presentation03_2.pdf) + openSUSE.org: An evaluation of business impact is not yet done, this + work is being considered due to the parallels in gains accepted that is + known to exist for qemu as with the work that is being done to address + dead-code for Xen due to the switch to pvops to support Xen on Linux. A + business evaluation of impact of the gains of this can be assessed once + tools are written to help evaluate the amount of dead-code in a project + at run time. At least one public evaluation (https://www.internetsociety.org/sites/default/files/Presentation03_2.pdf) has been done already to quantify the amount of dead-code, evaluated as exposed code attack surface, this evaluation concludes that at least on the Linux kernel a tailored kernel which removes not needed or unused kernel configuration and therefore access to run time code, reduces the attack surface by 85%. -- openSUSE Feature: https://features.opensuse.org/320868