Compile-time stack validation for Livepatch

Compile-time stack validation

original

In order to get their code upstream, they must first invest considerable effort into
fixing a related subsystem. Live patching is exactly a case in point.

Live patch’s dilemma

Consistecy Model

“Consistecy model” remained unsettled, even ther core code had been merged.
Ensuring that a patch is applied to a live kernel if it is safe to do so;

1. that job includes checking to be sure that the affected functions are not
   executing at the time the patch is applied.
2. Don’t cause crash during patching.

Atempts

• Freeze all:
  One way of ensuring that a given function is not executing is to freeze all processes
  on the system, then examine the call stack of each to see which functions are active
  all the time. – used by kPatch and kGraft.
  But, strong opposition came for a simple reason: the information in the kernel’s
  call stack is often not reliable.
  for example: assembly code that does not set up proper stack frames

At the time, 100% reliable stack traces were not widely seen as an attainable goal. It is certainly possible to fix up all of the assembly code that does not set up proper stack frames (assuming it could all be found), but, since nothing in the kernel’s normal operation depends on good call-stack information, there was nothing preventing things from breaking again at any time. In the absence of some sort of ongoing assurance that the kernel’s call stack will always remain valid, it is hard to be confident that a live-patching system won’t do the wrong thing.

Conclusion

In the absence of some sort of ongoing assurance that the kernel’s call stack
will always remain valid, it is hard to be confident that a live-patching system won’t do the wrong thing.

• Assembly code calls another function without setting up new stack frame.
  The validation tool checks to make sure that function calls are surrounded by the appropriate frame-maintenance code.
  There are currently assembly macros to do this work, but they are unused; Josh’s patch renames them to FRAME_BEGIN and FRAME_END and puts them into use.
  Versions of these macros for inline assembly in C code have also been added; they can be found in <asm/frame.h>.
• Dynmamic jumps
  for the most part, they are only allowed as part of a C switch statement.
  for “siling calls”, where the end of one function jumps to the beginning of another and the frame pointer hasn’t changed.

Validating the call stack

Josh Poimboeuf find a wat to make the call stack valid at all times and keep it
that way, named “compile-time stack metadata validation”.
This work adds a new tool (called stacktool)
that checks the entire kernel as part of the build process to be sure that all
code obeys the rules for maintaining the call stack.

Every function in assembly code must be marked aas a callable function(ELF function type)