Welcome to Deker!

  • Purpose
The reason for making a separate library for deker was to make it easy to verify part of the code by redefining only related part.
  • The technique used
Any function that needs to be redefined is declared with attribute, __attribute__((weak)). This allows that function to picked up from libdeker while compiling. The build system compiles in a way that libdeker gets priority over liblcd.
  • How to use it to redefine any particular method
  1. Put macro LIBDEKER_WEAK_ATTR against the method that needs to be redefined in libdeker
  2. Define the function in libdeker folder in a file with the same name as the original file of the function. You can have same directory structure as the original file but it is not necessary.
  3. Modify the Kbuild.libdeker file in scripts folder to reflect the newly created file. For example, if the function that needs to be redefined belongs to the file libdeker/libcap/cap.c then modify the Kbuild.libdeker file as follows:
            lib-y += $(addprefix libdeker/libcap/, \
                         cap.o \
                       ) 
  1. build the libdeker with command: make libdeker DEKER=1

Note: Steps to setup libdeker for the first time:

  1. Set the path to binaries for variables CLANG_PATH, WLLVM_PATH, WLLVM_EXTRACT_BC_PATH, SMACK_INCLUDE_PATH, SMACK_LIB_PATH
  2. Clone all the submodules for the repository

Generate bitcode for vmlinux

  • Purpose
The purpose of generating bitcode on whole vmlinux binary is to do interprocedural analysis on the whole Linux kernel. Ideally, we would like to get which members of data structures are updated inside a function. For e.g., when register_filesystem() function is called what are all the data structures that gets updated inside that function.

How to disable optimization

Though, we can extract bitcode files, for SMACK tool to work we have to have the kernel compiled using -O0. When you switch from -O2 to -O0 on the top level Makefile, it would obviously crash, failing to compile some of the inline assembly code. Don't give up, there is a way.

  • Goto the respective Makefile of the file that failed to compile
  • add ccflags-y += -O1 to it

This would make sure that the files compiled using the modified Makefile would get -O1 instead of global -O0. Verify the changes using make V=1. Be surprised if you don't encounter any further issues. You will. I have encountered linker failures on '__compiletime_assert' functions. I had to replace that macro with a dummy one to compile it successfully.

Steps for IDL auto-generation

  • Initial steps
    • Suppose we would like to isolate a module say foo.ko, aggregate all bc files of those object files which would be compiled to form foo.ko
    • Find out the list of undefined functions within that module. These functions are defined somewhere else. Some of them are helpers which are probably redefined inside liblcd, but many others are not.
    • Find out the list of unused functions inside that module. These will mostly be function pointers defined within this module, but gets called from outside. This can also be due to poorly written code which has unused functions. From this step, we should be able to get another list of functions that are function pointers. With DSA, it should be possible to cross verify whether these are really function pointers.