Several improvements
* Drop the detection of EFI through kallsyms. This detection is no
longer useful since commit 2c0c4c9fd1 ("Using CONFIG_EFI instead of
user defined HAS_EFI (#1036)") replaced `HAS_EFI` with `CONFIG_EFI`.
* Use `...-objs-y` and `...-objs-$(CONFIG_...)` logic to choose which
`cpu.asm` file is being built. This is something that other modules do
in Linux kernel source.
* Introduce `quiet_cmd_...` and `cmd_...` definition in order to use the
build system of the kernel to compile `cpu.asm` with NASM. This should
prevent issues like the one mentioned in 2210002bab ("Fixed build
error on latest Ubuntu") from happening again. Moreover this makes the
custom clean command `rm -f ${asm-path}/cpu.o` no longer necessary.
* Remove variables which become unused after these changes. Now, all
that `Makefile` needs is a kernel directory, specified with `KSRC`.
This change has been tested on a test system running Ubuntu 20.10 and on
GitHub Actions workers running Ubuntu 16.04, 18.04 and 20.04 on Linux
5.4.0-1040-azure. It has also been compile-tested on many other Linux
distributions using a work-in-progress GitHub Actions configuration
(https://github.com/fishilico/chipsec/actions/runs/661200380).
While debugging issues on Linux systems using clang CFI (Control Flow
Integrity, `CONFIG_CFI_CLANG`), it appeared to me that
`chipsec_lookup_name` could be simplified.
- Instead of using `set_fs(KERNEL_DS);` to invoke read operations,
`kernel_read` can directly be used. This function existed since at
least Linux 2.4.0
(https://elixir.bootlin.com/linux/2.4.0/source/fs/exec.c#L368) so
there should not be compatibility issues.
- Instead of allocating a 128-byte buffer with `kmalloc`, use a stack
buffer. While at it, fix a buffer overflow issue on systems with large
symbol names such as ones using clang's CFI: some lines were 142
characters long.
- Instead of matching anything on the line of `/proc/kallsyms` with
`strstr`, only do prefix-matching on the start of the symbol name.
This involves counting spaces in the line, in order to extract the
name as the 3rd item.
- Last but not least, show a clear error message if the symbol is not
found in /proc/kallsyms. This helps debugging issues.
While at it, add a comment which explains why reading `/proc/kallsyms`
does not work with Linux 5.10.
As `drivers/linux/Makefile` uses `KSRC` to define the kernel source
directory, override this variable in DKMS configuration directly.
This fixes building the Linux kernel module with dkms on Ubuntu 20.04.
It was previously possible to build Chipsec kernel module for a different Linux
kernel than the running one, and ff4a273 broke that possibility.
Bring that back just by giving a way to override the KSRC variable when calling
the Makefile.
Fix issue #1122
drivers/linux/Makefile:
* Replaced KERNEL_SRC_DIR variable with KSRC.
* Added KSRC variable which should enable successful DKMS compilation,
as opposed to bailing out with "Unable to find the Linux source tree."
This patch has been tested on Black Arch.
* Some function pointers misuse caught by PaX RAP. These workaround fix would be useful
to the vanilla kernel since the recent TigerLake support Intel CET which might have
the same complaints if the implementation can achieve the current level as PaX RAP.
* Static call is a hack to make the function pointer writable. Please keep in mind that
this hack is only for the firmware audit reason. Be cautions if you intend to do the similar
things in production.
Thanks to Spender and PaX team points out the way to fix.
Signed-off-by: Shawn C <citypw@hardenedlinux.org>
in name of security reasons. The current workaround is get the kallsyms_lookup_name()
via kprobe if the kernel >= v5.10.
Signed-off-by: Shawn C <citypw@hardenedlinux.org>
PaX implements valid_mmap_phys_addr_range in the kernel, and the
(return 1) hack in chipsec_km.c has a name collision with it.
Add another conditional for exposing the definition predicated on
whether __HAVE_ARCH_PAX_OPEN_USERLAND is defined in the kernel
headers. If it is, dont redefine the original function.