Misplaced Pages

#568431

22-709: It takes the form of an in-tree kernel module . As of 2022, AMD Kernel Fusion Driver ( KFD ) is now integrated in this one kernel module. AMD KFD development at AMD is part of ROCm , under the ROCk project. AMDgpu has been fully upstreamed and new developments continue to do so. As AMDgpu is part of the monolithic Linux kernel, it is shipped by most Linux distributions directly. The package suite / install script amdgpu-pro, distributed by AMD directly from AMD Radeon Software , ships an AMDgpu kernel module somewhat reliably more up-to-date compared to that of kernels shipped in regular operating system distributions. The development of

44-407: A consulting company that releases proprietary device drivers as loadable kernel modules, attempted to abuse a null terminator in their MODULE_LICENSE , as visible in the following code excerpt: The string comparison code used by the kernel at the time tried to determine whether the module was GPLed stopped when it reached a null character ( \0 ), so it was fooled into thinking that the module

66-509: A kernel parameter and some Linux distributions enabled it by default. This Linux -related article is a stub . You can help Misplaced Pages by expanding it . Loadable kernel module In computing , a loadable kernel module ( LKM ) is an object file that contains code to extend the running kernel , or so-called base kernel , of an operating system . LKMs are typically used to add support for new hardware (as device drivers ) and/or filesystems , or for adding system calls . When

88-402: A proprietary or non-GPL-compatible module will set a 'taint' flag in the running kernel—meaning that any problems or bugs experienced will be less likely to be investigated by the maintainers. LKMs effectively become part of the running kernel, so can corrupt kernel data structures and produce bugs that may not be able to be investigated if the module is indeed proprietary. In 2004, Linuxant,

110-446: Is maintained only within a branch. While loadable kernel modules are a convenient method of modifying the running kernel, this can be abused by attackers on a compromised system to prevent detection of their processes or files , allowing them to maintain control over the system. Many rootkits make use of LKMs in this way. Note that, on most operating systems, modules do not help privilege elevation in any way, as elevated privilege

132-627: Is only possible from the Trusted Path when the system is running with the Immutable Global Zone feature enabled. Lsmod lsmod is a command on Linux systems. It shows which loadable kernel modules are currently loaded. An example terminal print after running lsmod command: "Module" denotes the name of the module. "Size" denotes the size of the module (not memory used) in Bytes. "Used by" shows that number of times

154-485: Is part of System Integrity Protection . In older versions of macOS, or if kext signing is disabled, a loadable kernel module in a kernel extension bundle can be loaded by non-root users if the OSBundleAllowUserLoad property is set to True in the bundle's property list. However, if any of the files in the bundle, including the executable code file, are not owned by root and group wheel, or are writable by

176-683: Is placed within the .modinfo section of loadable ELF modules. This versioning information can be compared with that of the running kernel before loading a module; if the versions are incompatible, the module will not be loaded. Other operating systems, such as Solaris , FreeBSD , macOS , and Windows keep the kernel API and ABI relatively stable, thus avoiding this problem. For example, FreeBSD kernel modules compiled against kernel version 6.0 will work without recompilation on any other FreeBSD 6.x version, e.g. 6.4. However, they are not compatible with other major versions and must be recompiled for use with FreeBSD 7.x, as API and ABI compatibility

198-425: Is required to load a LKM; they merely make it easier for the attacker to hide the break-in. Linux allows disabling module loading via sysctl option /proc/sys/kernel/modules_disabled . An initramfs system may load specific modules needed for a machine at boot and then disable module loading. This makes the security very similar to a monolithic kernel. If an attacker can change the initramfs, they can change

220-400: The modprobe command. They are located in /lib/modules or /usr/lib/modules and have had the extension .ko ("kernel object") since version 2.6 (previous versions used the .o extension). The lsmod command lists the loaded kernel modules. In emergency cases, when the system fails to boot due to e.g. broken modules, specific modules can be enabled or disabled by modifying

242-459: The kldload command, unloaded with kldunload , and listed with kldstat . Modules can also be loaded from the loader before the kernel starts, either automatically (through /boot/loader.conf ) or by hand. Some loadable kernel modules in macOS can be loaded automatically. Loadable kernel modules can also be loaded by the kextload command. They can be listed by the kextstat command. Loadable kernel modules are located in bundles with

SECTION 10

#1732786861569

264-577: The NetWare server, and they have .NLM as the file name extension. A downloadable kernel module (DKM) type project can be created to generate a ".out" file which can then be loaded to kernel space using "ld" command. This downloadable kernel module can be unloaded using "unld" command. Solaris has a configurable kernel module load path, which defaults to /platform/platform-name/kernel /kernel /usr/kernel . Most kernel modules live in subdirectories under /kernel ; those not considered necessary to boot

286-497: The base kernel code is never fragmented. Once the system is in a state in which modules may be inserted, for example once the filesystems have been mounted that contain the modules, it is likely that any new kernel code insertion will cause the kernel to become fragmented, thereby introducing a minor performance penalty by using more TLB entries, causing more TLB misses. Loadable kernel modules in Linux are loaded (and unloaded) by

308-424: The base kernel. Much of that functionality would reside in memory without being used, wasting memory , and would require that users rebuild and reboot the base kernel every time they require new functionality. One minor criticism of preferring a modular kernel over a static kernel is the so-called fragmentation penalty . The base kernel is always unpacked into real contiguous memory by its setup routines; thus,

330-610: The extension .kext . Modules supplied with the operating system are stored in the /System/Library/Extensions directory; modules supplied by third parties are in various other directories. A NetWare kernel module is referred to as a NetWare Loadable Module (NLM). NLMs are inserted into the NetWare kernel by means of the LOAD command, and removed by means of the UNLOAD command; the modules command lists currently loaded kernel modules. NLMs may reside in any valid search path assigned on

352-1082: The functionality provided by an LKM is no longer required, it can be unloaded in order to free memory and other resources. Most current Unix-like systems and Microsoft Windows support loadable kernel modules under different names, such as kernel loadable module ( kld ) in FreeBSD , kernel extension ( kext ) in macOS (although support for third-party modules is being dropped ), kernel extension module in AIX , dynamically loadable kernel module in HP-UX , kernel-mode driver in Windows NT and downloadable kernel module ( DKM ) in VxWorks . They are also known as kernel loadable modules (or KLM ), and simply as kernel modules ( KMOD ). Without loadable kernel modules, an operating system would have to include all possible anticipated functionality compiled directly into

374-634: The group or "other", the attempt to load the kernel loadable module will fail. Kernel modules can optionally have a cryptographic signature ELF section which is verified on load depending on the Verified Boot policy settings. The kernel can enforce that modules are cryptographically signed by a set of trusted certificates; the list of trusted certificates is held outside of the OS in the ILOM on some SPARC based platforms. Userspace initiated kernel module loading

396-487: The kernel binary. In OS X Yosemite and later releases, a kernel extension has to be code-signed with a developer certificate that holds a particular "entitlement." Such a developer certificate is only provided by Apple on request and not automatically given to Apple Developer members. This feature, called "kext signing", is enabled by default and it instructs the kernel to stop booting if unsigned kernel extensions are present. In OS X El Capitan and later releases, it

418-454: The kernel boot parameters list (for example, if using GRUB , by pressing 'e' in the GRUB start menu, then editing the kernel parameter line). In the opinion of Linux maintainers, LKM are derived works of the kernel . The Linux maintainers tolerate the distribution of proprietary modules, but allow symbols to be marked as only available to GNU General Public License (GPL) modules. Loading

440-432: The kernel module happens between AMD and the Linux maintainers, discussions happen on the freedesktop.org mailing lists - freedesktop being home to major Linux graphics projects such as Mesa , libdrm , Xorg , Wayland . AMDgpu officially supports cards built upon GCN 1.2 or higher, including new instruction sets such as RDNA 1&2, CDNA. Though as of 2022 support for GCN 1.0/1.1 is incomplete, it can be enabled by

462-460: The system to the point that init can start are often (but not always) found in /usr/kernel . When running a DEBUG kernel build the system actively attempts to unload modules. Linux does not provide a stable API or ABI for kernel modules. This means that there are differences in internal structure and function between different kernel versions, which can cause compatibility problems. In an attempt to combat those problems, symbol versioning data

SECTION 20

#1732786861569

484-426: Was declaring its license to be just "GPL". Kernel modules for FreeBSD are stored within /boot/kernel/ for modules distributed with the operating system , or usually /boot/modules/ for modules installed from FreeBSD ports or FreeBSD packages , or for proprietary or otherwise binary-only modules. FreeBSD kernel modules usually have the extension .ko . Once the machine has booted, they may be loaded with

#568431