Modal Title
Open Source / Operations / Security

What Do You Know about Your Linux System?

A look at the process to get insight into supported system calls and features and to assess how secure a system is and its runtime activity.
Apr 3rd, 2023 11:15am by
Featued image for: What Do You Know about Your Linux System?

Do you know that Linux kernel-supported system calls and features are architecture dependent? Do you know that Linux kernel supports several hardening configuration options to secure your system?

Let’s take a look at the process to get insight into supported system calls and features and to assess how secure a system is and its runtime activity.

System State Visualization

The kernel system state can be viewed as a combination of static and dynamic features and modules. Let’s first define what static and runtime system states are, and then explore how we can visualize the static and runtime system parts of the kernel.

Static System View comprises system calls, features, static and dynamic modules enabled in the kernel configuration.

Runtime System View comprises system calls, ioctls invoked and subsystems used during the runtime. A workload could load and unload modules and change the runtime system configuration to suit its needs by tuning system parameters.

A few key points to remember:

  • Supported system calls and Linux kernel features are architecture-dependent. System call numbering is different on different architectures.
  • auditd,, and tools can be used to discover supported system calls and features.
  • Understanding Linux kernel-hardening configuration options and making sure they are enabled will make a system more secure.
  • Employing runtime tracing can shed light on the runtime system state.
  • Workloads could change the system state by loading and unloading dynamic modules and tuning system parameters.

How Do We Check Supported System Calls?

We have tools at our disposal to check for supported system calls and features. We can get the supported system call information using auditd utilities.

ausyscall –dump from the auditd family of tools prints out the supported system calls on a system and allows mapping syscall names and numbers. You can install the auditd package on Debian-based systems:

Linux kernel tool scripts/ can be used to check if current architecture is missing any system calls compared to i386.

Linux kernel tool scripts/ can be used to list the Kernel feature support matrix for an architecture.

Finding Supported System Calls

As mentioned earlier, ausyscall prints out supported system calls on a system and allows mapping syscalls names and numbers.

ausyscall allows filtering on specific system calls or key strings. Let’s see what it shows when we invoke ausyscall with “open” and “time” options:

Finding Unsupported System Calls

Understanding which system calls are not supported is important as well. As mentioned earlier, scripts/ checks missing system calls on current architecture compared to i386.

Let’s check this against ausyscall now.

As you can see, ausyscall shows mmap2, ftruncate64 and ftruncate64 aren’t implemented on this system. This matches what shows.

Finding Supported Features

Let’s see how we can find the supported features on a system. scripts/ can be used to list the kernel feature support matrix for an architecture.

This script parses Documentation/features to find the support status information. It can be used to validate the contents of the files under Documentation/features or simply list them:

Here is how you can find if stack protector and thread-info-in-task features are supported:

Finding Kernel Module Status

lsmod command shows the kernel modules that are currently loaded. This program displays the contents of /proc/modules. Let’s pick uvcvideo module, which is found on most laptops:

You can see that lsmod shows uvcvideo and the modules it depends on, and how many modules are using them. videobuf2_common is in use by four other modules. In other words, this is the reference count for this module, and rmmod will refuse to unload it as long as the reference count is > 0.

You can get the same information from /proc/modules:

The information is similar with a few extra fields. The address is the base address for the module in kernel virtual memory space. When run as a normal user, the address is all zeros. The same command when run as root will be as follows:

Let’s now take a look at what modinfo shows us:

This tells us that this module is built in the kernel repository signed with a build time autogenerated key.

Let’s do one last sanity check on the system to see if the following two command outputs match:

If they don’t match, examine your system closely. Kernel rootkits install their own ps, find, etc., utilities to mask their activity. The outputs match on my system. Do they match on yours?

Is My System as Secure as It Could Be?

The Linux kernel supports several hardening options to make the system secure. Let’s talk about kconfig-hardened-check tool sanity that can check kernel configuration for security. You can clone the latest kconfig-hardened-check repository:

This will generate a detailed report of kernel security configuration and command line options that are enabled (OK) and the ones that aren’t (FAIL), and a summary line at the end:

You will have to analyze the information to determine which options make sense to enable on your system.

Understanding System Runtime Activity

So far, we have looked for ways to find the static state of a system. Now let’s switch to the runtime state of a system. The Linux kernel event-tracing feature can help us with understanding the runtime state.

Enabling event tracing gives insight into system runtime activity. This is a good way to identify which parts of the kernel are used at a higher level while the system is in and/or while a specific workload/process is running.

Event tracing depends on the CONFIG_EVENT_TRACING option enabled. You can enable event tracing before starting workload/process. Event tracing allows you to enable and disable tracing on supported/available events at runtime.

You can find available events, tracers and filter functions in the following files:

Now this is how you can enable tracing:

Once the workload/process stops or when you decide you have the status you need, you can disable event tracing:

You can find the tracing information in the file: /sys/kernel/debug/tracing

Here is the information shown in this file:

How Do We Use These Traces?

You can map the functions to system calls and other kernel features to get insight into the overall system activity while a workload/process is running.


As you can see, we have several tools and features at our disposal to get insight into system activity and assess it for security.


Group Created with Sketch.
TNS owner Insight Partners is an investor in: Pragma.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.