{"id":13380054,"url":"https://github.com/lkrg-org/lkrg","last_synced_at":"2025-03-13T06:32:13.613Z","repository":{"id":37409255,"uuid":"285020891","full_name":"lkrg-org/lkrg","owner":"lkrg-org","description":"Linux Kernel Runtime Guard","archived":false,"fork":false,"pushed_at":"2024-07-06T17:41:45.000Z","size":1344,"stargazers_count":406,"open_issues_count":85,"forks_count":72,"subscribers_count":22,"default_branch":"main","last_synced_at":"2024-07-30T08:06:19.044Z","etag":null,"topics":["hardening","integrity","kernel","linux","security"],"latest_commit_sha":null,"homepage":"https://lkrg.org","language":"C","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"other","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/lkrg-org.png","metadata":{"files":{"readme":"README","changelog":"CHANGES","contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2020-08-04T15:27:11.000Z","updated_at":"2024-07-30T08:06:26.914Z","dependencies_parsed_at":"2023-10-25T14:07:25.728Z","dependency_job_id":"260850e7-141d-4ab7-a5b8-c027966eba34","html_url":"https://github.com/lkrg-org/lkrg","commit_stats":null,"previous_names":["openwall/lkrg"],"tags_count":10,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/lkrg-org%2Flkrg","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/lkrg-org%2Flkrg/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/lkrg-org%2Flkrg/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/lkrg-org%2Flkrg/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/lkrg-org","download_url":"https://codeload.github.com/lkrg-org/lkrg/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":243357996,"owners_count":20277988,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["hardening","integrity","kernel","linux","security"],"created_at":"2024-07-30T08:00:57.783Z","updated_at":"2025-03-13T06:32:13.097Z","avatar_url":"https://github.com/lkrg-org.png","language":"C","funding_links":[],"categories":["Linux","Mobile"],"sub_categories":["Kernel","Linux/ *Nix"],"readme":"Linux Kernel Runtime Guard (LKRG)\n=================================\n\nLKRG performs runtime integrity checking of the Linux kernel and detection of\nsecurity vulnerability exploits against the kernel.\n\nLKRG is a kernel module (not a kernel patch), so it can be built for and loaded\non top of a wide range of mainline and distros' kernels, without needing to\npatch those.  We currently support kernel versions ranging from as far back as\nRHEL7's (and its many clones/revisions) and Ubuntu 16.04's to latest mainline\nand distros' kernels.  Our Continuous Integration setup has tested this version\nof LKRG with up to latest mainline kernel 6.11.0-061100daily20240916-generic\nas available for Ubuntu on the release date.\n\nLKRG currently supports the x86-64, 32-bit x86, AArch64 (ARM64), and 32-bit ARM\nCPU architectures.\n\nPlease refer to CONCEPTS for concepts behind LKRG and for information on its\nefficacy, and to PERFORMANCE for information on its performance impact.\n\nThe following sections describe how to obtain LKRG sources, build LKRG, test\nit, install it on the system, and customize its configuration.\n\n\nGetting the sources\n-------------------\n\nFor LKRG releases and latest source code, please refer to its homepage:\n\n\thttps://lkrg.org\n\nTo download this release from there and verify it, you would have used commands\nlike the below:\n\n\twget https://www.openwall.com/signatures/openwall-offline-signatures.asc\n\tgpg --import openwall-offline-signatures.asc\n\twget https://lkrg.org/download/lkrg-0.9.9.tar.gz.sign\n\twget https://lkrg.org/download/lkrg-0.9.9.tar.gz\n\tgpg --verify lkrg-0.9.9.tar.gz.sign lkrg-0.9.9.tar.gz\n\nPlease preserve the GnuPG key above and also use it to verify future releases,\nwhich will most likely work in a similar manner.\n\nLatest LKRG development source code is hosted on GitHub, from where you can\nclone the git repository to a local directory using the following command:\n\n\tgit clone https://github.com/lkrg-org/lkrg\n\n\nBuild requirements\n------------------\n\nTo build LKRG, you will need the following software:\n\n- GNU make\n\n- GCC, ideally the same version of it that was used to build the kernel itself\n  (some people manage with clang, but this is unsupported, so expect issues)\n\n- libelf, including its \"development\" sub-package, in case your target kernel\n  was built with CONFIG_UNWINDER_ORC=y\n\n- A kernel build directory corresponding to the Linux kernel image the module\n  is to run on.\n\nFor example, under Debian and Ubuntu you can install all of these with:\n\n\tsudo apt-get install make gcc libelf-dev linux-headers-$(uname -r)\n\nand under Red Hat'ish distributions (e.g. RHEL, CentOS, Fedora) with:\n\n\tsudo yum install make gcc elfutils-libelf-devel kernel-devel\n\n(For documentation purposes, we prefix commands requiring root access with\n\"sudo\", but you may of course run them as root by different means.)\n\n\nBuilding\n--------\n\nWith the above requirements satisfied, you should be able to easily build LKRG\nby running \"make\" when you're in LKRG's top level source code directory.\nBuilding LKRG does not require root, and thus shouldn't be done as root.\n\nTo speed up the building, we recommend specifying a parallel job count matching\nyour machine's logical CPU count, e.g. like this:\n\n\tmake -j8\n\n\nTesting\n-------\n\nWe recommend that before you install LKRG on the system such that it would be\nstarted on bootup, you manually test loading the LKRG module into the kernel\nwithout making the setup permanent.  We also recommend that you keep LKRG's\ndetection of kernel integrity violations enabled for this test, yet change\nits enforcement action from kernel panic (the default) to mere logging.\nThis way, you can safely detect potential system-specific false positives and\nonly proceed with installation if there are none.\n\nYou can do this for a freshly built LKRG (and while you're still in its top\nlevel source code directory) with the following command:\n\n\tsudo insmod output/lkrg.ko kint_enforce=1\n\nThen check kernel messages for any potential errors, use the system for a long\nwhile, and check again:\n\n\tsudo dmesg\n\n(Depending on kernel version and system configuration, the \"dmesg\" command\nmight not require root.)\n\nUnload LKRG from the kernel with:\n\n\tsudo rmmod lkrg\n\nso that it can then be loaded using the same procedure that's used on system\nbootup and without the parameter override.\n\n\nInstallation\n------------\n\nIf your Linux distribution uses a supported init system (systemd or OpenRC),\nyou can install LKRG with:\n\n\tsudo make install\n\nwhile you're still in its top level source code directory.\n\nWe don't in any way favor one init system over another, and would gladly add\nsupport for more of them if there's demand, or especially if we receive such\ncontributions.  Meanwhile, on a distribution without a supported init system\nyou can let \"sudo make install\" partially complete (up to the point where it\nfinds you're not using a supported init system).\n\nRun the following command to start the LKRG service, for systemd:\n\n\tsudo systemctl start lkrg\n\nfor OpenRC:\n\n\tsudo /etc/init.d/lkrg start\n\nfor other:\n\n\tsudo modprobe -v lkrg\n\n\nAutoload on bootup\n------------------\n\nIn order to automatically load LKRG into the Linux kernel on each bootup run\nthe following command, for systemd:\n\n\tsudo systemctl enable lkrg\n\nfor OpenRC:\n\n\tsudo rc-update add lkrg boot\n\nfor other:\n\n\tsudo mkdir -p /etc/modules-load.d/ \u0026\u0026\n\t\techo lkrg | sudo tee /etc/modules-load.d/lkrg.conf\n\nAlternatively, you can put the \"modprobe lkrg\" command into a system startup\nscript.  Please note that ideally this command would run before sysctl files\n(especially /etc/sysctl.d/01-lkrg.conf) are processed, or otherwise the LKRG\nsettings specified in those would not take effect.\n\n\nInstalling using DKMS\n---------------------\n\nDKMS enables kernel modules to be dynamically built for each kernel version.\nWhat this means in effect is that on kernel upgrades the module is rebuilt.\nYou can install LKRG using DKMS as well.  For instance, on Red Hat'ish\ndistributions after following the shared download instructions above:\n\n\tsudo tar -xzf lkrg-0.9.9.tar.gz -C /usr/src/\n\tsudo dnf update -y\n\tsudo dnf install kernel-devel dkms openssl\n\tsudo dkms add -m lkrg -v 0.9.9\n\tsudo dkms build -m lkrg -v 0.9.9\n\tsudo dkms install -m lkrg -v 0.9.9\n\nThe only difference on other distributions should be the installation of the\nkernel headers, the DKMS utility, and OpenSSL.  Install the headers for the\ntarget kernels.\n\nYou can then query the status with:\n\n\tdkms status\n\nIf everything is right, you should get similar output to the following:\n\n\tlkrg/0.9.9, 5.18.9-200.fc36.x86_64, x86_64: installed\n\nPlease refer to the previous two sections for how to start the LKRG service or\nhave it started on system bootup.  If you wish to use the unit/init file, you\nmust install it manually, e.g., by running the `lkrg-bootup.sh` script\nlocated under `scripts/bootup/` with the `install` subcommand (as root).\n\n\nUninstalling\n------------\n\nSimilarly to installation, you can uninstall LKRG using \"make\" as well:\n\n\tsudo make uninstall\n\nwhile you're in the top level source code directory of the installed version.\n\nIf you installed using DKMS, you'd uninstall with:\n\n\tsudo dkms remove -m lkrg/0.9.9 --all\n\nYou can also use the following command to temporarily stop the LKRG service\nwithout uninstalling it, for systemd:\n\n\tsudo systemctl stop lkrg\n\nfor OpenRC:\n\n\tsudo /etc/init.d/lkrg stop\n\nfor other:\n\n\tsudo modprobe -v -r lkrg\n\n\nUpgrading\n---------\n\nOur suggested way to upgrade LKRG is to start by uninstalling the old version.\n\nYou can then follow the Testing and Installation steps for the new version.\n\n\nRecovery\n--------\n\nTo account for the hopefully unlikely, but really unfortunate event that some\nincompatibility between the Linux kernel or other components of the system and\nLKRG isn't detected prior to LKRG installation, yet leads to system crash on\nbootup, we've included support for the \"nolkrg\" kernel parameter.  Thus, you\nmay disable LKRG by specifying \"nolkrg\" on the kernel command-line via your\nbootloader.  The system should then boot up without LKRG, and thus without\ntriggering the problem, letting you fix it.  You must be aware though, that you\nwill not be able to manually load the LKRG module if the kernel was booted with\nthis parameter.\n\n\nModule parameters\n-----------------\n\nThe LKRG kernel module supports a number of parameters, including kint_enforce\nalready mentioned above and many more.\n\nFor freshly built LKRG, you can list the parameters with:\n\n\tmodinfo output/lkrg.ko\n\nwhile you're still in LKRG's top level source code directory.\n\nWith LKRG installed on the system, you can list them with:\n\n\tsudo modinfo lkrg\n\n(Depending on system configuration, \"modinfo\" might not require root.)\n\nParameters can be specified on command-lines of \"insmod\", \"modprobe\", or after\n\"options lkrg \" in a file in the /etc/modprobe.d directory.\n\nFor descriptions of the parameters and their default and possible values,\nplease refer to the following two sections.\n\n\nRemote logging configuration (load-time only)\n---------------------------------------------\n\nLKRG supports the following module parameters (with default values or lack\nthereof specified in braces) to enable its optional remote logging.\n\n- net_server_addr (no default)\n  Log server IPv4 address (e.g., 127.0.0.1)\n\n- net_server_port (514)\n  Log server TCP port number\n\n- net_server_pk (no default)\n  Log server public key (64 hexadecimal digits)\n\nIf you're starting LKRG via a systemd unit or startup script (such as those\nprovided in here), our recommended way to specify the above parameters is by\ncreating the file /etc/modprobe.d/lkrg.conf with something like this in it:\n\noptions lkrg net_server_addr=127.0.0.1 net_server_pk=64hexdigitshere\n\nPlease refer to LOGGING on how to use the corresponding userspace components.\n\n\nLoad-time and runtime configuration\n-----------------------------------\n\nBesides the parameters optionally specified when loading the module into the\nkernel, LKRG also supports a number of sysctl's, which can be used to adjust\nits behavior when it is already loaded into the kernel.  For each feature that\nis configurable at both load time and run time, we have a module parameter and\na sysctl of similar name (the module parameters lack the \"lkrg.\" prefix, but\nare otherwise the same), so the below documentation is mostly usable for both.\n\nTo list all LKRG sysctl's and their current values, use:\n\n\tsudo sysctl -a | grep lkrg\n\nThe sysctl's are (with default values specified in braces):\n\n- lkrg.profile_validate (3)\n  Quick choice of a pre-defined profile controlling whether, when, and to what\n  extent LKRG validates system integrity and detects attacks.  Allowed values\n  are 0 (disabled), 1 (light), 2 (balanced), 3 (heavy), and 4 (paranoid).\n  Additionally, this setting will read as 9 (custom) if an underlying setting\n  is changed directly (potentially deviating from any of the profiles).\n\n  Higher-numbered validation profiles provide higher likelihood of timely\n  detection of an attack, but involve higher performance overhead and higher\n  risk of incompatibility with other system software.  Profiles 1 to 3 provide\n  reasonable tradeoffs.\n\n  lkrg.profile_validate=3 or higher is incompatible with VirtualBox hosts,\n  where you need to use at most lkrg.profile_validate=2.  However, there's no\n  problem with setting lkrg.profile_validate=3 on Linux+LKRG guest systems in\n  VirtualBox VMs.\n\n  lkrg.profile_validate=4 (paranoid) is incompatible with many distributions\n  and has unreasonably high performance overhead and poor scalability while not\n  necessarily providing a practically relevant improvement in attack detection.\n\n  Choosing a validation profile sets the following underlying settings, which\n  are described further below: kint_validate, pint_validate, pcfi_validate,\n  umh_validate, smep_validate, smap_validate, and msr_validate.\n\n- lkrg.profile_enforce (2)\n  Quick choice of a pre-defined profile controlling whether and how LKRG acts\n  on detected integrity violations and attacks.  Allowed values are 0 (log and\n  accept), 1 (selective), 2 (strict), and 3 (paranoid).  Additionally, this\n  setting will read as 9 (custom) if an underlying setting is changed directly\n  (potentially deviating from any of the profiles).\n\n  Higher-numbered enforcement profiles provide higher likelihood of mitigating\n  a compromise or stopping an attack, but also a higher risk of interfering\n  with normal system behavior and to a worse extent in case of false positives.\n\n  lkrg.profile_enforce=0 can be used for safe testing of LKRG, where any\n  detected violations and attacks are logged but no enforcement is performed.\n  It can also be useful where LKRG is meant to act as a sensor within a larger\n  security monitoring and response setup (e.g., network-wide).\n\n  lkrg.profile_enforce=1 performs selective enforcement - log only for kernel\n  integrity violations, varying effective actions ranging from killing a task\n  to triggering a kernel panic for other types of violations and attacks.\n  This mode is extremely unlikely to panic the kernel on a false positive.\n\n  lkrg.profile_enforce=2 performs strict enforcement - varying effective\n  actions for all types of violations and attacks, including triggering a\n  kernel panic for kernel integrity violations.\n\n  lkrg.profile_enforce=3 performs the most paranoid enforcement - kernel panic\n  for all types of violations and attacks.\n\n  Choosing an enforcement profile sets the following underlying settings, which\n  are described further below: kint_enforce, pint_enforce, pcfi_enforce,\n  umh_enforce, smep_enforce, and smap_enforce.\n\n  Also relevant is the kernel's kernel.panic sysctl and panic parameter, which\n  makes the system reboot on kernel panic.  For example, kernel.panic=60 in\n  /etc/sysctl.conf or in a file under the /etc/sysctl.d directory, or panic=60\n  on the kernel's command-line, will make the system reboot in 60 seconds after\n  a panic.  This provides a brief opportunity to read the panic message on the\n  console yet makes an unattended server try to come back up on its own.\n\n  Profiles are currently available via sysctl only - there are no corresponding\n  module parameters.  However, the individual underlying settings, which are\n  described further below, do have their corresponding module parameters.\n\n- lkrg.heartbeat (0)\n  Whether or not to print a heartbeat message (\"System is clean!\" or \"Tasks are\n  clean!\" depending on other configuration) whenever the global integrity\n  checking routine completes with no violations detected.  Allowed values are 0\n  (don't print the message) and 1 (print the message if allowed by log_level).\n\n- lkrg.interval (15)\n  LKRG's timer interval for periodic invocation of the global integrity\n  checking routine, in seconds.  Allowed values are 5 to 1800.\n\n- lkrg.trigger (N/A)\n  Force LKRG to invoke the global integrity checking routine.  If you set this\n  to 1, the routine is immediately invoked and this sysctl is reset back to 0.\n\n- lkrg.log_level (3)\n  LKRG's logging verbosity level.  Allowed values are from 0 to 4 for normal\n  builds or from 0 to 6 for debugging builds.\n\n  Values of 4 and higher are meant for debugging only and produce too verbose\n  logging for production use.  Moreover, some messages logged at those high\n  levels contain information useful for kernel vulnerability exploitation,\n  making those log levels potentially mildly insecure (depending on other\n  system configuration).\n\n- lkrg.block_modules (0)\n  Whether or not to block further loading of kernel modules.  Allowed values\n  are 0 (no) and 1 (yes).\n\n  This feature is meant primarily to prevent unintended user-triggered (or\n  attacker-triggered) auto-loading of maybe-vulnerable modules provided in a\n  distribution after all intended modules have already been loaded.  This\n  feature is not effective (nor is meant to be) against attackers who already\n  have root privileges and try to load a module explicitly (they could simply\n  flip this setting or even unload LKRG first).\n\n  Please note that enabling this setting (too) early (e.g., using the module\n  parameter or /etc/sysctl.*) may cause the system to fail to complete bootup\n  (if required modules are still being loaded in later stages of bootup, which\n  varies between distributions and system configurations).\n\n  Also relevant is the kernel's kernel.modules_disabled sysctl, which fully\n  disables module loading until the system is rebooted.\n\n- lkrg.hide (0)\n  Whether or not LKRG should hide itself from the lists of loaded modules and\n  KOBJs.  Allowed values are 0 (do not hide LKRG, or unhide it if previously\n  hidden) and 1 (hide LKRG).\n\n  Please note that LKRG can be easily detected by other means anyway, such as\n  through the presence of its sysctl's.\n\n- lkrg.kint_validate (3)\n  Whether and when to validate global kernel integrity.  Allowed values are 0\n  (disabled), 1 (only when manually triggered by lkrg.trigger), 2 (also\n  periodically every lkrg.interval seconds), and 3 (also periodically every\n  lkrg.interval seconds and probabilistically on certain other events).\n\n  This currently applies to kernel and modules code and read-only data, global\n  SELinux settings, and some CPU status registers/bits (WP, SMEP, SMAP, MSRs).\n  (The validation and enforcement of SMEP, SMAP, and MSRs are separately\n  controlled by their respective knobs described below, and SMEP and SMAP are\n  validated much more frequently, not only as part of global kernel integrity.)\n\n- lkrg.kint_enforce (2)\n  How to act on global kernel integrity violations.  Allowed values are 0 (log\n  once and accept new likely-compromised state as valid), 1 (log only for most\n  violations, log the violation and restore previous state for SELinux and CPU\n  WP bit), and 2 (panic the kernel).\n\n  Note that lkrg.kint_enforce=1 is expected to produce repeated log messages on\n  most kernel integrity violations, which can be noisy.  Also note that\n  lkrg.kint_enforce=2 is unfortunately the only way to make full use of LKRG's\n  global kernel integrity validation.  Running with lkrg.kint_validate=2 or\n  higher but lkrg.kint_enforce set to 0 or 1 wastes CPU time on costly checks\n  without achieving a corresponding security improvement, except that it might\n  provide logs for post-mortem detection and analysis of a security compromise.\n\n- lkrg.pint_validate (2)\n  Whether and when to validate process credentials integrity.  Allowed values\n  are 0 (disabled), 1 (validate a task's credentials just before it'd make use\n  of the credentials), 2 (currently, it has the same meaning as 1), and 3\n  (validate credentials of all tasks in the system whenever any task is about\n  to make use of its credentials).\n\n  Except with lkrg.pint_validate=0, we also validate the credentials of all\n  tasks as part of LKRG's global integrity checking routine.\n\n  lkrg.pint_validate=1 is sufficient to provide most of LKRG's potential at\n  timely detection of exploits.  lkrg.pint_validate=3 is a paranoid mode with\n  high performance overhead yet likely a minuscule gain in security.\n\n- lkrg.pint_enforce (1)\n  How to act on process credentials integrity violations.  Allowed values are 0\n  (log once and accept new likely-compromised state as valid), 1 (kill the\n  task), and 2 (panic the kernel).\n\n  In Linux kernel's terminology, which we also use here, a \"task\" refers to a\n  thread, and threads of a program may technically have different credentials.\n  Our enforcement of process credentials integrity is thus per-thread, and e.g.\n  it might happen that we kill an individual compromised thread of a program.\n\n- lkrg.pcfi_validate (2)\n  Whether and to what extent to validate Control Flow Integrity (CFI) on kernel\n  functions that we monitor because of their usefulness for exploits' Return\n  Oriented Programming (ROP) chains.  Allowed values are 0 (disabled), 1 (only\n  validate the stack pointer), and 2 (also validate all stack frames).\n\n  Because of the very limited extent of validation performed, we call our CFI\n  mechanism pCFI, for poor man's CFI.\n\n  lkrg.pcfi_validate=2 is incompatible with VirtualBox hosts, where you need to\n  use at most lkrg.pcfi_validate=1.  However, there's no problem with setting\n  lkrg.pcfi_validate=2 on Linux+LKRG guest systems in VirtualBox VMs.\n\n- lkrg.pcfi_enforce (1)\n  How to act on pCFI violations.  Allowed values are 0 (log only), 1 (kill the\n  task), and 2 (panic the kernel).\n\n  Note that lkrg.pcfi_enforce=0 may produce repeated log messages for the same\n  violation, which might occasionally be noisy.\n\n- lkrg.umh_validate (1)\n  Whether and to what extent to validate uses of usermodehelper (UMH).  Allowed\n  values are 0 (validation disabled), 1 (allow only previously known programs),\n  and 2 (completely block UMH).\n\n  UMH can also be protected with pCFI regardless of this setting.\n\n  UMH is a kernel-internal interface, which the kernel uses to invoke programs\n  such as /sbin/modprobe (to auto-load a module on demand) and many others.\n  When left unrestricted, UMH is convenient for kernel vulnerability exploits.\n\n- lkrg.umh_enforce (1)\n  How to act on UMH usage violations.  Allowed values are 0 (log only), 1\n  (prevent execution), and 2 (panic the kernel).\n\n- lkrg.smep_validate (1)\n  Whether or not to validate the Supervisor Mode Execution Protection (SMEP)\n  bit on supporting x86-64 CPUs.  Allowed values are 0 (no) and 1 (yes).\n\n- lkrg.smep_enforce (2)\n  How to act on unexpected changes of the SMEP bit.  Allowed values are 0 (log\n  once and accept new likely-compromised state as valid), 1 (log the violation\n  and restore original value), and 2 (panic the kernel).\n\n- lkrg.smap_validate (1)\n  Whether or not to validate the Supervisor Mode Access Prevention (SMAP) bit\n  on supporting x86-64 CPUs.  Allowed values are 0 (no) and 1 (yes).\n\n- lkrg.smap_enforce (2)\n  How to act on unexpected changes of the SMAP bit.  Allowed values are 0 (log\n  once and accept new likely-compromised state as valid), 1 (log the violation\n  and restore original value), and 2 (panic the kernel).\n\n- lkrg.msr_validate (0)\n  Whether or not to validate CPU Model Specific Registers (MSRs) as part of the\n  global integrity checking routine.  Allowed values are 0 (no) and 1 (yes).\n\n  This is currently specific to x86(-64) CPUs.\n\n  There are situations where such validation is undesirable, such as if you run\n  LKRG on a host machine that manages VMs and dynamically reconfigures MSRs.\n  This is known to be the case for KVM and VirtualBox hosts, where this setting\n  needs to be disabled.  However, there's no problem with enabling this setting\n  on Linux+LKRG guest systems in VMs on those hosts, and indeed on systems that\n  don't run KVM and VirtualBox.\n\nThat's all for now.  Greetings from the LKRG team!\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Flkrg-org%2Flkrg","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Flkrg-org%2Flkrg","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Flkrg-org%2Flkrg/lists"}