Initial LKM support

[vobst]

This PR adds support for the analysis of ELF relocatable object files in general and Linux loadable kernel modules (LKMs) as a special case.

Commit 01 contains the changes that are necessary to generate a RuntimeMemoryImage of those files. Commit 02 adds special logic for analyzing LKMs.

See the commit messages (replicated below for convenience) for more details.

lib: RuntimeMemoryImage: support relocatable object files

Add initial support for the analysis of relocatable object files. These
files do not include information about the runtime memory layout, i.e.,
segments. Ghidra handles such files by assigning addresses to sections
in `ElfProgramBuilder.processSectionHeaders`. The algorithm is
essentially:

```
base_address <- 0x100_000

for each section in section_headers do:
  if not section.is_alloc() or section.sh_type == SHT_NULL or
     section.size == 0 then:
     continue
  end if

  alignment <- section.sh_addralign

  section.address <- align(base_address, alignment)

  base_address <- base_address + section.sh_size
end for
```

Importantly, the above is not the exact algorithm used by Ghidra, but only
an approximation that aims to be correct for the invocation of Ghidra
with the pcode extractor plugin.

Add an implementation of this algorithm to `MemorySegment` and use it
from `MemoryImage::new` when an relocatable object file is given.

config: add separate config for LKMs

Add a separate configuration file for Linux loadable kernel modules (LKMs). Use
this one instead of the default configuration when analyzing an LKM and install
it to the same location as the default configuration. Limit the checks
that are executed to those that make sense in kernel space.

Cases where an LKM is analyzed are recognized by checking if a
relocatable object file contains the ".modinfo" and
".gnu.linkonce.this_module" sections.

Multiple checks, e.g., CWE789, CWE416, and CWE134, require more work to
function properly for LKMs. We mainly need to teach the cew_checker
about the parameters and semantics of some functions. They are included,
but effectively disabled since their configuration is empty. CWE467
actually works since the functions are called the same as in user space
and thus Ghidra recognizes their parameters.

[Enkelmann]

The code looks good with only minor change requests from my side (as long as bumping the minimal required Rust version does not lead to follow-up problems). There are still two things missing that should be part of this PR:

• We need to mention in the documentation that we now have experimental support for Linux kernel modules. It is probably enough to change it in the Readme.md, but we should take a look at whether we also need to mention it in the main doc comment of the lib.rs file.
• We still need to add some kind of acceptance test, so that we get alerted if a future PR breaks this feature. We should probably do it similar to what we did for bare metal support: Add a very simple precompiled kernel module (containing e.g. a simple Null dereference) and use it in a corresponding acceptance test. As long as the support is still marked as experimental, we do not need our full test pipeline with test cases for many different architectures.

[vobst]

The code looks good with only minor change requests from my side (as long as bumping the minimal required Rust version does not lead to follow-up problems). There are still two things missing that should be part of this PR:

Thanks!

• We need to mention in the documentation that we now have experimental support for Linux kernel modules. It is probably enough to change it in the Readme.md, but we should take a look at whether we also need to mention it in the main doc comment of the lib.rs file.

See docs: mention experimental LKM support

• We still need to add some kind of acceptance test, so that we get alerted if a future PR breaks this feature. We should probably do it similar to what we did for bare metal support: Add a very simple precompiled kernel module (containing e.g. a simple Null dereference) and use it in a corresponding acceptance test. As long as the support is still marked as experimental, we do not need our full test pipeline with test cases for many different architectures.

See test: add acceptance tests for LKM support

[Enkelmann]

Very nice, only some typos remaining.
Could you also merge the master branch into this branch? Since your other PR to bump the minimal Rust version is now merged, this should fix the failing CI check.

[vobst]

Very nice, only some typos remaining. Could you also merge the master branch into this branch? Since your other PR to bump the minimal Rust version is now merged, this should fix the failing CI check.

Done, seems like the build succeeded.

[Enkelmann]

LGTM