+ landlock

+.. SPDX-License-Identifier: GPL-2.0

+.. Copyright © 2025 Microsoft Corporation

+

+================================

+Landlock: system-wide management

+================================

+

+:Author: Mickaël Salaün

+:Date: March 2025

+

+Landlock can leverage the audit framework to log events.

+

+User space documentation can be found here:

+Documentation/userspace-api/landlock.rst.

+

+Audit

+=====

+

+Denied access requests are logged by default for a sandboxed program if `audit`

+is enabled. This default behavior can be changed with the

+sys_landlock_restrict_self() flags (cf.

+Documentation/userspace-api/landlock.rst). Landlock logs can also be masked

+thanks to audit rules. Landlock can generate 2 audit record types.

+

+Record types

+------------

+

+AUDIT_LANDLOCK_ACCESS

+ This record type identifies a denied access request to a kernel resource.

+ The ``domain`` field indicates the ID of the domain that blocked the

+ request. The ``blockers`` field indicates the cause(s) of this denial

+ (separated by a comma), and the following fields identify the kernel object

+ (similar to SELinux). There may be more than one of this record type per

+ audit event.

+

+ Example with a file link request generating two records in the same event::

+

+ domain=195ba459b blockers=fs.refer path="/usr/bin" dev="vda2" ino=351

+ domain=195ba459b blockers=fs.make_reg,fs.refer path="/usr/local" dev="vda2" ino=365

+

+AUDIT_LANDLOCK_DOMAIN

+ This record type describes the status of a Landlock domain. The ``status``

+ field can be either ``allocated`` or ``deallocated``.

+

+ The ``allocated`` status is part of the same audit event and follows

+ the first logged ``AUDIT_LANDLOCK_ACCESS`` record of a domain. It identifies

+ Landlock domain information at the time of the sys_landlock_restrict_self()

+ call with the following fields:

+

+ - the ``domain`` ID

+ - the enforcement ``mode``

+ - the domain creator's ``pid``

+ - the domain creator's ``uid``

+ - the domain creator's executable path (``exe``)

+ - the domain creator's command line (``comm``)

+

+ Example::

+

+ domain=195ba459b status=allocated mode=enforcing pid=300 uid=0 exe="/root/sandboxer" comm="sandboxer"

+

+ The ``deallocated`` status is an event on its own and it identifies a

+ Landlock domain release. After such event, it is guarantee that the

+ related domain ID will never be reused during the lifetime of the system.

+ The ``domain`` field indicates the ID of the domain which is released, and

+ the ``denials`` field indicates the total number of denied access request,

+ which might not have been logged according to the audit rules and

+ sys_landlock_restrict_self()'s flags.

+

+ Example::

+

+ domain=195ba459b status=deallocated denials=3

+

+

+Event samples

+--------------

+

+Here are two examples of log events (see serial numbers).

+

+In this example a sandboxed program (``kill``) tries to send a signal to the

+init process, which is denied because of the signal scoping restriction

+(``LL_SCOPED=s``)::

+

+ $ LL_FS_RO=/ LL_FS_RW=/ LL_SCOPED=s LL_FORCE_LOG=1 ./sandboxer kill 1

+

+This command generates two events, each identified with a unique serial

+number following a timestamp (``msg=audit(1729738800.268:30)``). The first

+event (serial ``30``) contains 4 records. The first record

+(``type=LANDLOCK_ACCESS``) shows an access denied by the domain `1a6fdc66f`.

+The cause of this denial is signal scopping restriction

+(``blockers=scope.signal``). The process that would have receive this signal

+is the init process (``opid=1 ocomm="systemd"``).

+

+The second record (``type=LANDLOCK_DOMAIN``) describes (``status=allocated``)

+domain `1a6fdc66f`. This domain was created by process ``286`` executing the

+``/root/sandboxer`` program launched by the root user.

+

+The third record (``type=SYSCALL``) describes the syscall, its provided

+arguments, its result (``success=no exit=-1``), and the process that called it.

+

+The fourth record (``type=PROCTITLE``) shows the command's name as an

+hexadecimal value. This can be translated with ``python -c

+'print(bytes.fromhex("6B696C6C0031"))'``.

+

+Finally, the last record (``type=LANDLOCK_DOMAIN``) is also the only one from

+the second event (serial ``31``). It is not tied to a direct user space action

+but an asynchronous one to free resources tied to a Landlock domain

+(``status=deallocated``). This can be useful to know that the following logs

+will not concern the domain ``1a6fdc66f`` anymore. This record also summarize

+the number of requests this domain denied (``denials=1``), whether they were

+logged or not.

+

+.. code-block::

+

+ type=LANDLOCK_ACCESS msg=audit(1729738800.268:30): domain=1a6fdc66f blockers=scope.signal opid=1 ocomm="systemd"

+ type=LANDLOCK_DOMAIN msg=audit(1729738800.268:30): domain=1a6fdc66f status=allocated mode=enforcing pid=286 uid=0 exe="/root/sandboxer" comm="sandboxer"

+ type=SYSCALL msg=audit(1729738800.268:30): arch=c000003e syscall=62 success=no exit=-1 [..] ppid=272 pid=286 auid=0 uid=0 gid=0 [...] comm="kill" [...]

+ type=PROCTITLE msg=audit(1729738800.268:30): proctitle=6B696C6C0031

+ type=LANDLOCK_DOMAIN msg=audit(1729738800.324:31): domain=1a6fdc66f status=deallocated denials=1

+

+Here is another example showcasing filesystem access control::

+

+ $ LL_FS_RO=/ LL_FS_RW=/tmp LL_FORCE_LOG=1 ./sandboxer sh -c "echo > /etc/passwd"

+

+The related audit logs contains 8 records from 3 different events (serials 33,

+34 and 35) created by the same domain `1a6fdc679`::

+

+ type=LANDLOCK_ACCESS msg=audit(1729738800.221:33): domain=1a6fdc679 blockers=fs.write_file path="/dev/tty" dev="devtmpfs" ino=9

+ type=LANDLOCK_DOMAIN msg=audit(1729738800.221:33): domain=1a6fdc679 status=allocated mode=enforcing pid=289 uid=0 exe="/root/sandboxer" comm="sandboxer"

+ type=SYSCALL msg=audit(1729738800.221:33): arch=c000003e syscall=257 success=no exit=-13 [...] ppid=272 pid=289 auid=0 uid=0 gid=0 [...] comm="sh" [...]

+ type=PROCTITLE msg=audit(1729738800.221:33): proctitle=7368002D63006563686F203E202F6574632F706173737764

+ type=LANDLOCK_ACCESS msg=audit(1729738800.221:34): domain=1a6fdc679 blockers=fs.write_file path="/etc/passwd" dev="vda2" ino=143821

+ type=SYSCALL msg=audit(1729738800.221:34): arch=c000003e syscall=257 success=no exit=-13 [...] ppid=272 pid=289 auid=0 uid=0 gid=0 [...] comm="sh" [...]

+ type=PROCTITLE msg=audit(1729738800.221:34): proctitle=7368002D63006563686F203E202F6574632F706173737764

+ type=LANDLOCK_DOMAIN msg=audit(1729738800.261:35): domain=1a6fdc679 status=deallocated denials=2

+

+

+Event filtering

+---------------

+

+If you get spammed with audit logs related to Landlock, this is either an

+attack attempt or a bug in the security policy. We can put in place some

+filters to limit noise with two complementary ways:

+

+- with sys_landlock_restrict_self()'s flags if we can fix the sandboxed

+ programs,

+- or with audit rules (see :manpage:`auditctl(8)`).

+

+Additional documentation

+========================

+

+* `Linux Audit Documentation`_

+* Documentation/userspace-api/landlock.rst

+* Documentation/security/landlock.rst

+* https://landlock.io

+

+.. Links

+.. _Linux Audit Documentation:

+ https://github.com/linux-audit/audit-documentation/wiki

+ "make gconfig" GTK based configuration tool.

+ symbol values from either arch/$ARCH/configs/defconfig

+.. SPDX-License-Identifier: GPL-2.0

+

+Obsolete ABI Files

+==================

+

+.. kernel-abi:: obsolete

+ :no-symbols:

+.. SPDX-License-Identifier: GPL-2.0

+

+.. kernel-abi:: obsolete

+ :no-files:

+.. SPDX-License-Identifier: GPL-2.0

+

+Removed ABI Files

+=================

+

+.. kernel-abi:: removed

+ :no-symbols:

+.. SPDX-License-Identifier: GPL-2.0

+

+.. kernel-abi:: removed

+ :no-files:

+.. SPDX-License-Identifier: GPL-2.0

+

+Stable ABI Files

+================

+

+.. kernel-abi:: stable

+ :no-symbols:

+.. SPDX-License-Identifier: GPL-2.0

+

+.. kernel-abi:: stable

+ :no-files:

+.. SPDX-License-Identifier: GPL-2.0

+

+Testing ABI Files

+=================

+

+.. kernel-abi:: testing

+ :no-symbols:

+.. SPDX-License-Identifier: GPL-2.0

+

+.. kernel-abi:: testing

+ :no-files:

+.. SPDX-License-Identifier: GPL-2.0

+

+.. kernel-abi:: README

+

+ABI symbols

+-----------

+

+

+ABI files

+---------

+

+.. toctree::

+ :maxdepth: 2

+

+ abi-stable-files

+ abi-testing-files

+ abi-obsolete-files

+ abi-removed-files

+ echo foo > /sys/block/zram0/comp_algorithm

+2) Select compression algorithm

+3) Set compression algorithm parameters: Optional

+4) Set Disksize

+5) Set memory limit: Optional

+6) Activate

+7) Add/remove zram devices

+8) Stats

+9) Deactivate

+10) Reset

+

+This freezer implementation is affected by shortcomings (see commit

+76f969e8948d8 ("cgroup: cgroup v2 freezer")) and cgroup v2 freezer is

+recommended.

+ Per memcg knob does not exist in cgroup v2.

+ Note that some kernel configurations might account complete larger

+ allocations (e.g., THP) towards 'rss' and 'mapped_file', even if

+ only some, but not all that memory is mapped.

+

+WARNING: cgroup2 cpu controller doesn't yet fully support the control of

+realtime processes. For a kernel built with the CONFIG_RT_GROUP_SCHED option

+enabled for group scheduling of realtime processes, the cpu controller can only

+be enabled when all RT processes are in the root cgroup. Be aware that system

+management software may already have placed RT processes into non-root cgroups

+during the system boot process, and these processes may need to be moved to the

+root cgroup before the cpu controller can be enabled with a

+CONFIG_RT_GROUP_SCHED enabled kernel.

+

+With CONFIG_RT_GROUP_SCHED disabled, this limitation does not apply and some of

+the interface files either affect realtime processes or account for them. See

+the following section for details. Only the cpu controller is affected by

+CONFIG_RT_GROUP_SCHED. Other controllers can be used for the resource control of

+realtime processes irrespective of CONFIG_RT_GROUP_SCHED.

+ brk(), sbrk(), and mmap(MAP_ANONYMOUS). Note that

+ some kernel configurations might account complete larger

+ allocations (e.g., THP) if only some, but not all the

+ memory of such an allocation is mapped anymore.

+ Amount of cached filesystem data mapped with mmap(). Note

+ that some kernel configurations might account complete

+ larger allocations (e.g., THP) if only some, but not

+ not all the memory of such an allocation is mapped.

+ pswpin (npn)

+ Number of pages swapped into memory

+

+ pswpout (npn)

+ Number of pages swapped out of memory

+

+ pgscan_proactive (npn)

+ Amount of scanned pages proactively (in an inactive LRU list)

+

+ pgsteal_proactive (npn)

+ Amount of reclaimed pages proactively

+

+ pgdemote_proactive

+ Number of pages demoted by proactively.

+

+integrity_key_size:<bytes>

+ Optionally set the integrity key size if it differs from the digest size.

+ It allows the use of wrapped key algorithms where the key size is

+ independent of the cryptographic key size.

+

+ I - inline mode - in this mode, dm-integrity will store integrity

+ data directly in the underlying device sectors.

+ The underlying device must have an integrity profile that

+ allows storing user integrity data and provides enough

+ space for the selected integrity tag.

+restart_on_error

+ Restart the system when an I/O error is detected.

+ This option can be combined with the restart_on_corruption option.

+

+panic_on_error

+ Panic the device when an I/O error is detected. This option is

+ not compatible with the restart_on_error option but can be combined

+ with the panic_on_corruption option.

+

+ If verity hashes are in cache and the IO size does not exceed the limit,

+ verify data blocks in bottom half instead of workqueue. This option can

+ reduce IO latency. The size limits can be configured via

+ /sys/module/dm_verity/parameters/use_bh_bytes. The four parameters

+ correspond to limits for IOPRIO_CLASS_NONE, IOPRIO_CLASS_RT,

+ IOPRIO_CLASS_BE and IOPRIO_CLASS_IDLE in turn.

+ For example:

+ <none>,<rt>,<be>,<idle>

+ 4096,4096,4096,4096

+ Just print an error message if an error occurs in a file data buffer.

+

+ Abort the journal if an error occurs in a file data buffer.

+Once the configuration is complete, the ``'live'`` attribute must be set to 1 in

+Once the configuration is complete, the ``'live'`` attribute must be set to 1 in

+ rsb

+.. SPDX-License-Identifier: GPL-2.0

+

+=======================

+RSB-related mitigations

+=======================

+

+.. warning::

+ Please keep this document up-to-date, otherwise you will be

+ volunteered to update it and convert it to a very long comment in

+ bugs.c!

+

+Since 2018 there have been many Spectre CVEs related to the Return Stack

+Buffer (RSB) (sometimes referred to as the Return Address Stack (RAS) or

+Return Address Predictor (RAP) on AMD).

+

+Information about these CVEs and how to mitigate them is scattered

+amongst a myriad of microarchitecture-specific documents.

+

+This document attempts to consolidate all the relevant information in

+once place and clarify the reasoning behind the current RSB-related

+mitigations. It's meant to be as concise as possible, focused only on

+the current kernel mitigations: what are the RSB-related attack vectors

+and how are they currently being mitigated?

+

+It's *not* meant to describe how the RSB mechanism operates or how the

+exploits work. More details about those can be found in the references

+below.

+

+Rather, this is basically a glorified comment, but too long to actually

+be one. So when the next CVE comes along, a kernel developer can

+quickly refer to this as a refresher to see what we're actually doing

+and why.

+

+At a high level, there are two classes of RSB attacks: RSB poisoning

+(Intel and AMD) and RSB underflow (Intel only). They must each be

+considered individually for each attack vector (and microarchitecture

+where applicable).

+

+----

+

+RSB poisoning (Intel and AMD)

+=============================

+

+SpectreRSB

+~~~~~~~~~~

+

+RSB poisoning is a technique used by SpectreRSB [#spectre-rsb]_ where

+an attacker poisons an RSB entry to cause a victim's return instruction

+to speculate to an attacker-controlled address. This can happen when

+there are unbalanced CALLs/RETs after a context switch or VMEXIT.

+

+* All attack vectors can potentially be mitigated by flushing out any

+ poisoned RSB entries using an RSB filling sequence

+ [#intel-rsb-filling]_ [#amd-rsb-filling]_ when transitioning between

+ untrusted and trusted domains. But this has a performance impact and

+ should be avoided whenever possible.

+

+ .. DANGER::

+ **FIXME**: Currently we're flushing 32 entries. However, some CPU

+ models have more than 32 entries. The loop count needs to be

+ increased for those. More detailed information is needed about RSB

+ sizes.

+

+* On context switch, the user->user mitigation requires ensuring the

+ RSB gets filled or cleared whenever IBPB gets written [#cond-ibpb]_

+ during a context switch:

+

+ * AMD:

+ On Zen 4+, IBPB (or SBPB [#amd-sbpb]_ if used) clears the RSB.

+ This is indicated by IBPB_RET in CPUID [#amd-ibpb-rsb]_.

+

+ On Zen < 4, the RSB filling sequence [#amd-rsb-filling]_ must be

+ always be done in addition to IBPB [#amd-ibpb-no-rsb]_. This is

+ indicated by X86_BUG_IBPB_NO_RET.

+

+ * Intel:

+ IBPB always clears the RSB:

+

+ "Software that executed before the IBPB command cannot control

+ the predicted targets of indirect branches executed after the

+ command on the same logical processor. The term indirect branch

+ in this context includes near return instructions, so these

+ predicted targets may come from the RSB." [#intel-ibpb-rsb]_

+

+* On context switch, user->kernel attacks are prevented by SMEP. User

+ space can only insert user space addresses into the RSB. Even

+ non-canonical addresses can't be inserted due to the page gap at the

+ end of the user canonical address space reserved by TASK_SIZE_MAX.

+ A SMEP #PF at instruction fetch prevents the kernel from speculatively

+ executing user space.

+

+ * AMD:

+ "Finally, branches that are predicted as 'ret' instructions get

+ their predicted targets from the Return Address Predictor (RAP).

+ AMD recommends software use a RAP stuffing sequence (mitigation

+ V2-3 in [2]) and/or Supervisor Mode Execution Protection (SMEP)

+ to ensure that the addresses in the RAP are safe for

+ speculation. Collectively, we refer to these mitigations as "RAP

+ Protection"." [#amd-smep-rsb]_

+

+ * Intel:

+ "On processors with enhanced IBRS, an RSB overwrite sequence may

+ not suffice to prevent the predicted target of a near return

+ from using an RSB entry created in a less privileged predictor

+ mode. Software can prevent this by enabling SMEP (for

+ transitions from user mode to supervisor mode) and by having

+ IA32_SPEC_CTRL.IBRS set during VM exits." [#intel-smep-rsb]_

+

+* On VMEXIT, guest->host attacks are mitigated by eIBRS (and PBRSB

+ mitigation if needed):

+

+ * AMD:

+ "When Automatic IBRS is enabled, the internal return address

+ stack used for return address predictions is cleared on VMEXIT."

+ [#amd-eibrs-vmexit]_

+

+ * Intel:

+ "On processors with enhanced IBRS, an RSB overwrite sequence may

+ not suffice to prevent the predicted target of a near return

+ from using an RSB entry created in a less privileged predictor

+ mode. Software can prevent this by enabling SMEP (for

+ transitions from user mode to supervisor mode) and by having

+ IA32_SPEC_CTRL.IBRS set during VM exits. Processors with

+ enhanced IBRS still support the usage model where IBRS is set

+ only in the OS/VMM for OSes that enable SMEP. To do this, such

+ processors will ensure that guest behavior cannot control the

+ RSB after a VM exit once IBRS is set, even if IBRS was not set

+ at the time of the VM exit." [#intel-eibrs-vmexit]_

+

+ Note that some Intel CPUs are susceptible to Post-barrier Return

+ Stack Buffer Predictions (PBRSB) [#intel-pbrsb]_, where the last

+ CALL from the guest can be used to predict the first unbalanced RET.

+ In this case the PBRSB mitigation is needed in addition to eIBRS.

+

+AMD RETBleed / SRSO / Branch Type Confusion

+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+

+On AMD, poisoned RSB entries can also be created by the AMD RETBleed

+variant [#retbleed-paper]_ [#amd-btc]_ or by Speculative Return Stack

+Overflow [#amd-srso]_ (Inception [#inception-paper]_). The kernel

+protects itself by replacing every RET in the kernel with a branch to a

+single safe RET.

+

+----

+

+RSB underflow (Intel only)

+==========================

+

+RSB Alternate (RSBA) ("Intel Retbleed")

+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+

+Some Intel Skylake-generation CPUs are susceptible to the Intel variant

+of RETBleed [#retbleed-paper]_ (Return Stack Buffer Underflow

+[#intel-rsbu]_). If a RET is executed when the RSB buffer is empty due

+to mismatched CALLs/RETs or returning from a deep call stack, the branch

+predictor can fall back to using the Branch Target Buffer (BTB). If a

+user forces a BTB collision then the RET can speculatively branch to a

+user-controlled address.

+

+* Note that RSB filling doesn't fully mitigate this issue. If there

+ are enough unbalanced RETs, the RSB may still underflow and fall back

+ to using a poisoned BTB entry.

+

+* On context switch, user->user underflow attacks are mitigated by the

+ conditional IBPB [#cond-ibpb]_ on context switch which effectively

+ clears the BTB:

+

+ * "The indirect branch predictor barrier (IBPB) is an indirect branch

+ control mechanism that establishes a barrier, preventing software

+ that executed before the barrier from controlling the predicted

+ targets of indirect branches executed after the barrier on the same

+ logical processor." [#intel-ibpb-btb]_

+

+* On context switch and VMEXIT, user->kernel and guest->host RSB

+ underflows are mitigated by IBRS or eIBRS:

+

+ * "Enabling IBRS (including enhanced IBRS) will mitigate the "RSBU"

+ attack demonstrated by the researchers. As previously documented,

+ Intel recommends the use of enhanced IBRS, where supported. This

+ includes any processor that enumerates RRSBA but not RRSBA_DIS_S."

+ [#intel-rsbu]_

+

+ However, note that eIBRS and IBRS do not mitigate intra-mode attacks.

+ Like RRSBA below, this is mitigated by clearing the BHB on kernel

+ entry.

+

+ As an alternative to classic IBRS, call depth tracking (combined with

+ retpolines) can be used to track kernel returns and fill the RSB when

+ it gets close to being empty.

+

+Restricted RSB Alternate (RRSBA)

+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+

+Some newer Intel CPUs have Restricted RSB Alternate (RRSBA) behavior,

+which, similar to RSBA described above, also falls back to using the BTB

+on RSB underflow. The only difference is that the predicted targets are

+restricted to the current domain when eIBRS is enabled:

+

+* "Restricted RSB Alternate (RRSBA) behavior allows alternate branch

+ predictors to be used by near RET instructions when the RSB is

+ empty. When eIBRS is enabled, the predicted targets of these

+ alternate predictors are restricted to those belonging to the

+ indirect branch predictor entries of the current prediction domain.

+ [#intel-eibrs-rrsba]_

+

+When a CPU with RRSBA is vulnerable to Branch History Injection

+[#bhi-paper]_ [#intel-bhi]_, an RSB underflow could be used for an

+intra-mode BTI attack. This is mitigated by clearing the BHB on

+kernel entry.

+

+However if the kernel uses retpolines instead of eIBRS, it needs to

+disable RRSBA:

+

+* "Where software is using retpoline as a mitigation for BHI or

+ intra-mode BTI, and the processor both enumerates RRSBA and

+ enumerates RRSBA_DIS controls, it should disable this behavior."

+ [#intel-retpoline-rrsba]_

+

+----

+

+References

+==========

+

+.. [#spectre-rsb] `Spectre Returns! Speculation Attacks using the Return Stack Buffer <https://arxiv.org/pdf/1807.07940.pdf>`_

+

+.. [#intel-rsb-filling] "Empty RSB Mitigation on Skylake-generation" in `Retpoline: A Branch Target Injection Mitigation <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/retpoline-branch-target-injection-mitigation.html#inpage-nav-5-1>`_

+

+.. [#amd-rsb-filling] "Mitigation V2-3" in `Software Techniques for Managing Speculation <https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/programmer-references/software-techniques-for-managing-speculation.pdf>`_

+

+.. [#cond-ibpb] Whether IBPB is written depends on whether the prev and/or next task is protected from Spectre attacks. It typically requires opting in per task or system-wide. For more details see the documentation for the ``spectre_v2_user`` cmdline option in Documentation/admin-guide/kernel-parameters.txt.

+

+.. [#amd-sbpb] IBPB without flushing of branch type predictions. Only exists for AMD.

+

+.. [#amd-ibpb-rsb] "Function 8000_0008h -- Processor Capacity Parameters and Extended Feature Identification" in `AMD64 Architecture Programmer's Manual Volume 3: General-Purpose and System Instructions <https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/programmer-references/24594.pdf>`_. SBPB behaves the same way according to `this email <https://lore.kernel.org/5175b163a3736ca5fd01cedf406735636c99a>`_.

+

+.. [#amd-ibpb-no-rsb] `Spectre Attacks: Exploiting Speculative Execution <https://comsec.ethz.ch/wp-content/files/ibpb_sp25.pdf>`_

+

+.. [#intel-ibpb-rsb] "Introduction" in `Post-barrier Return Stack Buffer Predictions / CVE-2022-26373 / INTEL-SA-00706 <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/post-barrier-return-stack-buffer-predictions.html>`_

+

+.. [#amd-smep-rsb] "Existing Mitigations" in `Technical Guidance for Mitigating Branch Type Confusion <https://www.amd.com/content/dam/amd/en/documents/resources/technical-guidance-for-mitigating-branch-type-confusion.pdf>`_

+

+.. [#intel-smep-rsb] "Enhanced IBRS" in `Indirect Branch Restricted Speculation <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/indirect-branch-restricted-speculation.html>`_

+

+.. [#amd-eibrs-vmexit] "Extended Feature Enable Register (EFER)" in `AMD64 Architecture Programmer's Manual Volume 2: System Programming <https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/programmer-references/24593.pdf>`_

+

+.. [#intel-eibrs-vmexit] "Enhanced IBRS" in `Indirect Branch Restricted Speculation <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/indirect-branch-restricted-speculation.html>`_

+

+.. [#intel-pbrsb] `Post-barrier Return Stack Buffer Predictions / CVE-2022-26373 / INTEL-SA-00706 <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/post-barrier-return-stack-buffer-predictions.html>`_

+

+.. [#retbleed-paper] `RETBleed: Arbitrary Speculative Code Execution with Return Instruction <https://comsec.ethz.ch/wp-content/files/retbleed_sec22.pdf>`_

+

+.. [#amd-btc] `Technical Guidance for Mitigating Branch Type Confusion <https://www.amd.com/content/dam/amd/en/documents/resources/technical-guidance-for-mitigating-branch-type-confusion.pdf>`_

+

+.. [#amd-srso] `Technical Update Regarding Speculative Return Stack Overflow <https://www.amd.com/content/dam/amd/en/documents/corporate/cr/speculative-return-stack-overflow-whitepaper.pdf>`_

+

+.. [#inception-paper] `Inception: Exposing New Attack Surfaces with Training in Transient Execution <https://comsec.ethz.ch/wp-content/files/inception_sec23.pdf>`_

+

+.. [#intel-rsbu] `Return Stack Buffer Underflow / Return Stack Buffer Underflow / CVE-2022-29901, CVE-2022-28693 / INTEL-SA-00702 <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/return-stack-buffer-underflow.html>`_

+

+.. [#intel-ibpb-btb] `Indirect Branch Predictor Barrier' <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/indirect-branch-predictor-barrier.html>`_

+

+.. [#intel-eibrs-rrsba] "Guidance for RSBU" in `Return Stack Buffer Underflow / Return Stack Buffer Underflow / CVE-2022-29901, CVE-2022-28693 / INTEL-SA-00702 <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/return-stack-buffer-underflow.html>`_

+

+.. [#bhi-paper] `Branch History Injection: On the Effectiveness of Hardware Mitigations Against Cross-Privilege Spectre-v2 Attacks <http://download.vusec.net/papers/bhi-spectre-bhb_sec22.pdf>`_

+

+.. [#intel-bhi] `Branch History Injection and Intra-mode Branch Target Injection / CVE-2022-0001, CVE-2022-0002 / INTEL-SA-00598 <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/branch-history-injection.html>`_

+

+.. [#intel-retpoline-rrsba] "Retpoline" in `Branch History Injection and Intra-mode Branch Target Injection / CVE-2022-0001, CVE-2022-0002 / INTEL-SA-00598 <https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/branch-history-injection.html>`_

+ * 'Mitigation: Reduced Speculation':

+ This mitigation gets automatically enabled when the above one "IBPB on

+ VMEXIT" has been selected and the CPU supports the BpSpecReduce bit.

+

+ It gets automatically enabled on machines which have the

+ SRSO_USER_KERNEL_NO=1 CPUID bit. In that case, the code logic is to switch

+ to the above =ibpb-vmexit mitigation because the user/kernel boundary is

+ not affected anymore and thus "safe RET" is not needed.

+

+ After enabling the IBPB on VMEXIT mitigation option, the BpSpecReduce bit

+ is detected (functionality present on all such machines) and that

+ practically overrides IBPB on VMEXIT as it has a lot less performance

+ impact and takes care of the guest->host attack vector too.

+The kernel exposes disk statistics via ``/proc/diskstats`` and

+``/sys/block/<device>/stat``. These stats are usually accessed via tools

+such as ``sar`` and ``iostat``.

+

+Here are examples using a disk with two partitions::

+

+ /proc/diskstats:

+ 259 0 nvme0n1 255999 814 12369153 47919 996852 81 36123024 425995 0 301795 580470 0 0 0 0 60602 106555

+ 259 1 nvme0n1p1 492 813 17572 96 848 81 108288 210 0 76 307 0 0 0 0 0 0

+ 259 2 nvme0n1p2 255401 1 12343477 47799 996004 0 36014736 425784 0 344336 473584 0 0 0 0 0 0

+

+ /sys/block/nvme0n1/stat:

+ 255999 814 12369153 47919 996858 81 36123056 426009 0 301809 580491 0 0 0 0 60605 106562

+

+ /sys/block/nvme0n1/nvme0n1p1/stat:

+ 492 813 17572 96 848 81 108288 210 0 76 307 0 0 0 0 0 0

+

+Both files contain the same 17 statistics. ``/sys/block/<device>/stat``

+contains the fields for ``<device>``. In ``/proc/diskstats`` the fields

+are prefixed with the major and minor device numbers and the device

+name. In the example above, the first stat value for ``nvme0n1`` is

+255999 in both files.

+

+The sysfs ``stat`` file is efficient for monitoring a small, known set

+of disks. If you're tracking a large number of devices,

+``/proc/diskstats`` is often the better choice since it avoids the

+overhead of opening and closing multiple files for each snapshot.

+

+All fields are cumulative, monotonic counters, except for field 9, which

+resets to zero as I/Os complete. The remaining fields reset at boot, on

+device reattachment or reinitialization, or when the underlying counter

+overflows. Applications reading these counters should detect and handle

+resets when comparing stat snapshots.

+ earlyprintk=mmio32,membase[,{nocfg|baudrate}]

+ earlyprintk=pciserial[,force],bus:device.function[,{nocfg|baudrate}]

+ Use "nocfg" to skip UART configuration, assume

+ BIOS/firmware has configured UART correctly.

+

+ The default is determined by

+ CONFIG_HARDENED_USERCOPY_DEFAULT_ON.

+ on Perform hardened usercopy checks.

+ hugepages= [HW,EARLY] Number of HugeTLB pages to allocate at boot.

+ [HW,EARLY] The size of the HugeTLB pages. This is

+ used in conjunction with hugepages (above) to

+ allocate huge pages of a specific size at boot. The

+ pair hugepagesz=X hugepages=Y can be specified once

+ for each supported huge page size. Huge page sizes

+ are architecture dependent. See also

+ hugepage_alloc_threads=

+ [HW] The number of threads that should be used to

+ allocate hugepages during boot. This option can be

+ used to improve system bootup time when allocating

+ a large amount of huge pages.

+ The default value is 25% of the available hardware threads.

+

+ Note that this parameter only applies to non-gigantic huge pages.

+

+ hugetlb_cma_only=

+ [HW,CMA,EARLY] When allocating new HugeTLB pages, only

+ try to allocate from the CMA areas.

+

+ This option does nothing if hugetlb_cma= is not also

+ specified.

+

+ hw_protection= [HW]

+ Format: reboot | shutdown

+

+ Hardware protection action taken on critical events like

+ overtemperature or imminent voltage loss.

+

+ no_cas

+ Do not enable capacity-aware scheduling (CAS) on

+ hybrid systems

+ * external: Mark port as external (hotplug-capable).

+

+ nosmt [KNL,MIPS,PPC,EARLY] Disable symmetric multithreading (SMT).

+ [KNL,X86,PPC,S390] Disable symmetric multithreading (SMT).

+ printk.debug_non_panic_cpus=

+ Allows storing messages from non-panic CPUs into

+ the printk log buffer during panic(). They are

+ flushed to consoles by the panic-CPU on

+ a best-effort basis.

+ Format: <bool> (1/Y/y=enable, 0/N/n=disable)

+ Default: disabled

+

+ rcutorture.test_boost_holdoff= [KNL]

+ Holdoff time (s) from start of test to the start

+ of RCU priority-boost testing. Defaults to zero,

+ that is, no holdoff.

+

+ Format: nn[KMG]:<align>:<label>

+ Selecting specific mitigation does not force enable

+ user mitigations.

+ NB: Both the mapped address and size must be page aligned for the architecture.

+

+ traceoff_after_boot

+ [FTRACE] Sometimes tracing is used to debug issues

+ during the boot process. Since the trace buffer has a

+ limited amount of storage, it may be prudent to

+ disable tracing after the boot is finished, otherwise

+ the critical information may be overwritten. With this

+ option, the main tracing buffer will be turned off at

+ the end of the boot process.

+

+ unaligned_scalar_speed=

+ [RISCV]

+ Format: {slow | fast | unsupported}

+ Allow skipping scalar unaligned access speed tests. This

+ is useful for testing alternative code paths and to skip

+ the tests in environments where they run too slowly. All

+ CPUs must have the same scalar unaligned access speed.

+

+ unaligned_vector_speed=

+ [RISCV]

+ Format: {slow | fast | unsupported}

+ Allow skipping vector unaligned access speed tests. This

+ is useful for testing alternative code paths and to skip

+ the tests in environments where they run too slowly. All

+ CPUs must have the same vector unaligned access speed.

+

+ e. If running on PowerMAC, build your kernel with

+ samsung-galaxybook

+.. SPDX-License-Identifier: GPL-2.0-or-later

+

+==========================

+Samsung Galaxy Book Driver

+==========================

+

+Joshua Grisham <josh@joshuagrisham.com>

+

+This is a Linux x86 platform driver for Samsung Galaxy Book series notebook

+devices which utilizes Samsung's ``SCAI`` ACPI device in order to control

+extra features and receive various notifications.

+

+Supported devices

+=================

+

+Any device with one of the supported ACPI device IDs should be supported. This

+covers most of the "Samsung Galaxy Book" series notebooks that are currently

+available as of this writing, and could include other Samsung notebook devices

+as well.

+

+Status

+======

+

+The following features are currently supported:

+

+- :ref:`Keyboard backlight <keyboard-backlight>` control

+- :ref:`Performance mode <performance-mode>` control implemented using the

+ platform profile interface

+- :ref:`Battery charge control end threshold

+ <battery-charge-control-end-threshold>` (stop charging battery at given

+ percentage value) implemented as a battery hook

+- :ref:`Firmware Attributes <firmware-attributes>` to allow control of various

+ device settings

+- :ref:`Handling of Fn hotkeys <keyboard-hotkey-actions>` for various actions

+- :ref:`Handling of ACPI notifications and hotkeys

+ <acpi-notifications-and-hotkey-actions>`

+

+Because different models of these devices can vary in their features, there is

+logic built within the driver which attempts to test each implemented feature

+for a valid response before enabling its support (registering additional devices

+or extensions, adding sysfs attributes, etc). Therefore, it can be important to

+note that not all features may be supported for your particular device.

+

+The following features might be possible to implement but will require

+additional investigation and are therefore not supported at this time:

+

+- "Dolby Atmos" mode for the speakers

+- "Outdoor Mode" for increasing screen brightness on models with ``SAM0427``

+- "Silent Mode" on models with ``SAM0427``

+

+.. _keyboard-backlight:

+

+Keyboard backlight

+==================

+

+A new LED class named ``samsung-galaxybook::kbd_backlight`` is created which

+will then expose the device using the standard sysfs-based LED interface at

+``/sys/class/leds/samsung-galaxybook::kbd_backlight``. Brightness can be

+controlled by writing the desired value to the ``brightness`` sysfs attribute or

+with any other desired userspace utility.

+

+.. note::

+ Most of these devices have an ambient light sensor which also turns

+ off the keyboard backlight under well-lit conditions. This behavior does not

+ seem possible to control at this time, but can be good to be aware of.

+

+.. _performance-mode:

+

+Performance mode

+================

+

+This driver implements the

+Documentation/userspace-api/sysfs-platform_profile.rst interface for working

+with the "performance mode" function of the Samsung ACPI device.

+

+Mapping of each Samsung "performance mode" to its respective platform profile is

+performed dynamically by the driver, as not all models support all of the same

+performance modes. Your device might have one or more of the following mappings:

+

+- "Silent" maps to ``low-power``

+- "Quiet" maps to ``quiet``

+- "Optimized" maps to ``balanced``

+- "High performance" maps to ``performance``

+

+The result of the mapping can be printed in the kernel log when the module is

+loaded. Supported profiles can also be retrieved from

+``/sys/firmware/acpi/platform_profile_choices``, while

+``/sys/firmware/acpi/platform_profile`` can be used to read or write the

+currently selected profile.

+

+The ``balanced`` platform profile will be set during module load if no profile

+has been previously set.

+

+.. _battery-charge-control-end-threshold:

+

+Battery charge control end threshold

+====================================

+

+This platform driver will add the ability to set the battery's charge control

+end threshold, but does not have the ability to set a start threshold.

+

+This feature is typically called "Battery Saver" by the various Samsung

+applications in Windows, but in Linux we have implemented the standardized

+"charge control threshold" sysfs interface on the battery device to allow for

+controlling this functionality from the userspace.

+

+The sysfs attribute

+``/sys/class/power_supply/BAT1/charge_control_end_threshold`` can be used to

+read or set the desired charge end threshold.

+

+If you wish to maintain interoperability with the Samsung Settings application

+in Windows, then you should set the value to 100 to represent "off", or enable

+the feature using only one of the following values: 50, 60, 70, 80, or 90.

+Otherwise, the driver will accept any value between 1 and 100 as the percentage

+that you wish the battery to stop charging at.

+

+.. note::

+ Some devices have been observed as automatically "turning off" the charge

+ control end threshold if an input value of less than 30 is given.

+

+.. _firmware-attributes:

+

+Firmware Attributes

+===================

+

+The following enumeration-typed firmware attributes are set up by this driver

+and should be accessible under

+``/sys/class/firmware-attributes/samsung-galaxybook/attributes/`` if your device

+supports them:

+

+- ``power_on_lid_open`` (device should power on when the lid is opened)

+- ``usb_charging`` (USB ports can deliver power to connected devices even when

+ the device is powered off or in a low sleep state)

+- ``block_recording`` (blocks access to camera and microphone)

+

+All of these attributes are simple boolean-like enumeration values which use 0

+to represent "off" and 1 to represent "on". Use the ``current_value`` attribute

+to get or change the setting on the device.

+

+Note that when ``block_recording`` is updated, the input device "Samsung Galaxy

+Book Lens Cover" will receive a ``SW_CAMERA_LENS_COVER`` switch event which

+reflects the current state.

+

+.. _keyboard-hotkey-actions:

+

+Keyboard hotkey actions (i8042 filter)

+======================================

+

+The i8042 filter will swallow the keyboard events for the Fn+F9 hotkey (Multi-

+level keyboard backlight toggle) and Fn+F10 hotkey (Block recording toggle)

+and instead execute their actions within the driver itself.

+

+Fn+F9 will cycle through the brightness levels of the keyboard backlight. A

+notification will be sent using ``led_classdev_notify_brightness_hw_changed``

+so that the userspace can be aware of the change. This mimics the behavior of

+other existing devices where the brightness level is cycled internally by the

+embedded controller and then reported via a notification.

+

+Fn+F10 will toggle the value of the "block recording" setting, which blocks

+or allows usage of the built-in camera and microphone (and generates the same

+Lens Cover switch event mentioned above).

+

+.. _acpi-notifications-and-hotkey-actions:

+

+ACPI notifications and hotkey actions

+=====================================

+

+ACPI notifications will generate ACPI netlink events under the device class

+``samsung-galaxybook`` and bus ID matching the Samsung ACPI device ID found on

+your device. The events can be received using userspace tools such as

+``acpi_listen`` and ``acpid``.

+

+The Fn+F11 Performance mode hotkey will be handled by the driver; each keypress

+will cycle to the next available platform profile.

+Input. If not set, then userspace is responsible for configuring an EDID.

+ | 2 - GMSL (one serializer, two daisy chained deserializers)

+ | 3 - GMSL (one serializer, two deserializers)

+ | 4 - GMSL (two deserializers with two daisy chain outputs)

+ - [RO] base_pfn: The base PFN (Page Frame Number) of the CMA area.

+ This is the same as ranges/0/base_pfn.

+ - [RO] bitmap: The bitmap of allocated pages in the area.

+ This is the same as ranges/0/base_pfn.

+ - [RO] ranges/N/base_pfn: The base PFN of contiguous range N

+ in the CMA area.

+ - [RO] ranges/N/bitmap: The bit map of allocated pages in

+ range N in the CMA area.

+ │ │ │ │ │ │ │ intervals_goal/access_bp,aggrs,min_sample_us,max_sample_us

+ │ │ │ │ │ │ │ :ref:`{core_,ops_,}filters <sysfs_filters>`/nr_filters

+ │ │ │ │ │ │ │ │ 0/type,matching,allow,memcg_path,addr_start,addr_end,target_idx,min,max

+- ``update_tuned_intervals``: Update the contents of ``sample_us`` and

+ ``aggr_us`` files of the kdamond with the auto-tuning applied ``sampling

+ interval`` and ``aggregation interval`` for the files. Please refer to

+ :ref:`intervals_goal section <damon_usage_sysfs_monitoring_intervals_goal>`

+ for more details.

+.. _damon_usage_sysfs_monitoring_intervals_goal:

+

+contexts/<N>/monitoring_attrs/intervals/intervals_goal/

+-------------------------------------------------------

+

+Under the ``intervals`` directory, one directory for automated tuning of

+``sample_us`` and ``aggr_us``, namely ``intervals_goal`` directory also exists.

+Under the directory, four files for the auto-tuning control, namely

+``access_bp``, ``aggrs``, ``min_sample_us`` and ``max_sample_us`` exist.

+Please refer to the :ref:`design document of the feature

+<damon_design_monitoring_intervals_autotuning>` for the internal of the tuning

+mechanism. Reading and writing the four files under ``intervals_goal``

+directory shows and updates the tuning parameters that described in the

+:ref:design doc <damon_design_monitoring_intervals_autotuning>` with the same

+names. The tuning starts with the user-set ``sample_us`` and ``aggr_us``. The

+tuning-applied current values of the two intervals can be read from the

+``sample_us`` and ``aggr_us`` files after writing ``update_tuned_intervals`` to

+the ``state`` file.

+

+In each scheme directory, seven directories (``access_pattern``, ``quotas``,

+``watermarks``, ``core_filters``, ``ops_filters``, ``filters``, ``stats``, and

+``tried_regions``) and three files (``action``, ``target_nid`` and

+``apply_interval``) exist.

+schemes/<N>/{core\_,ops\_,}filters/

+-----------------------------------

+Directories for :ref:`filters <damon_design_damos_filters>` of the given

+``core_filters`` and ``ops_filters`` directories are for the filters handled by

+the DAMON core layer and operations set layer, respectively. ``filters``

+directory can be used for installing filters regardless of their handled

+layers. Filters that requested by ``core_filters`` and ``ops_filters`` will be

+installed before those of ``filters``. All three directories have same files.

+

+Use of ``filters`` directory can make expecting evaluation orders of given

+filters with the files under directory bit confusing. Users are hence

+recommended to use ``core_filters`` and ``ops_filters`` directories. The

+``filters`` directory could be deprecated in future.

+

+In the beginning, the directory has only one file, ``nr_filters``. Writing a

+Each filter directory contains nine files, namely ``type``, ``matching``,

+``allow``, ``memcg_path``, ``addr_start``, ``addr_end``, ``min``, ``max``

+and ``target_idx``. To ``type`` file, you can write the type of the filter.

+Refer to :ref:`the design doc <damon_design_damos_filters>` for available type

+names, their meaning and on what layer those are handled.

+

+For ``memcg`` type, you can specify the memory cgroup of the interest by

+writing the path of the memory cgroup from the cgroups mount point to

+``memcg_path`` file. For ``addr`` type, you can specify the start and end

+address of the range (open-ended interval) to ``addr_start`` and ``addr_end``

+files, respectively. For ``hugepage_size`` type, you can specify the minimum

+and maximum size of the range (closed interval) to ``min`` and ``max`` files,

+respectively. For ``target`` type, you can specify the index of the target

+between the list of the DAMON context's monitoring targets list to

+``target_idx`` file.

+ # cd ops_filters/0/

+hugepage_alloc_threads

+ Specify the number of threads that should be used to allocate hugepages

+ during boot. This parameter can be used to improve system bootup time

+ when allocating a large amount of huge pages.

+ The default value is 25% of the available hardware threads.

+ Example to use 8 allocation threads::

+

+ hugepage_alloc_threads=8

+

+ Note that this parameter only applies to non-gigantic huge pages.

+ * Bit 58 pte is a guard region (since 6.15) (see madvise (2) man page)

+ * Bits 59-60 zero

+ Traditionally, bit 56 indicates that a page is mapped exactly once and bit

+ 56 is clear when a page is mapped multiple times, even when mapped in the

+ same process multiple times. In some kernel configurations, the semantics

+ for pages part of a larger allocation (e.g., THP) can differ: bit 56 is set

+ if all pages part of the corresponding large allocation are *certainly*

+ mapped in the same process, even if the page is mapped multiple times in that

+ process. Bit 56 is clear when any page page of the larger allocation

+ is *maybe* mapped in a different process. In some cases, a large allocation

+ might be treated as "maybe mapped by multiple processes" even though this

+ is no longer the case.

+

+ times each page is mapped, indexed by PFN. Some kernel configurations do

+ not track the precise number of times a page part of a larger allocation

+ (e.g., THP) is mapped. In these configurations, the average number of

+ mappings per page in this larger allocation is returned instead. However,

+ if any page of the large allocation is mapped, the returned value will

+ be at least 1.

+e.g. ``zswap.zpool=zsmalloc``. It can also be changed at runtime using the sysfs

+ echo zsmalloc > /sys/module/zswap/parameters/zpool

+The zsmalloc type zpool has a complex compressed page storage method, and it

+can achieve great storage densities.

+``cpuinfo_avg_freq``

+ An average frequency (in KHz) of all CPUs belonging to a given policy,

+ derived from a hardware provided feedback and reported on a time frame

+ spanning at most few milliseconds.

+

+ This is expected to be based on the frequency the hardware actually runs

+ at and, as such, might require specialised hardware support (such as AMU

+ extension on ARM). If one cannot be determined, this attribute should

+ not be present.

+

+ Note, that failed attempt to retrieve current frequency for a given

+ CPU(s) will result in an appropriate error, i.e: EAGAIN for CPU that

+ remains idle (raised on ARM).

+

+ seen by the hardware at the moment. This behavior though, is only

+ available via c:macro:``CPUFREQ_ARCH_CUR_FREQ`` option.

+interval" value. Otherwise, either the longest or the shortest (depending on

+which one is farther from the average) of the saved observed idle duration

+

+interval" is determined or too many data points are disregarded. In the latter

+case, if the size of the set of data points still under consideration is

+sufficiently large, the next idle duration is not likely to be above the largest

+idle duration value still in that set, so that value is taken as the predicted

+next idle duration. Finally, if the set of data points still under

+consideration is too small, no prediction is made.

+

+If the preliminary prediction of the next idle duration computed this way is

+long enough, the governor obtains the time until the closest timer event with

+the assumption that the scheduler tick will be stopped. That time, referred to

+as the *sleep length* in what follows, is the upper bound on the time before the

+next CPU wakeup. It is used to determine the sleep length range, which in turn

+is needed to get the sleep length correction factor.

+the two is taken as the final idle duration prediction.

+The ``no_acpi``, ``use_acpi`` and ``no_native`` module parameters are

+recognized by ``intel_idle`` if the kernel has been configured with ACPI

+support. In the case that ACPI is not configured these flags have no impact

+on functionality.

+

+``no_acpi`` - Do not use ACPI at all. Only native mode is available, no

+ACPI mode.

+

+``use_acpi`` - No-op in ACPI mode, the driver will consult ACPI tables for

+C-states on/off status in native mode.

+

+``no_native`` - Work only in ACPI mode, no native mode available (ignore

+all custom tables).

+``no_cas``

+ Do not enable capacity-aware scheduling (CAS) which is enabled by

+ default on hybrid systems.

+become the console, unless the kernel is configured with the

+CONFIG_NULL_TTY_DEFAULT_CONSOLE option, then it will default to using the

+ttynull device.

+

+``/proc/sys/fs/fuse/default_request_timeout`` is a read/write file for

+setting/getting the default timeout (in seconds) for a fuse server to

+reply to a kernel-issued request in the event where the server did not

+specify a timeout at mount. If the server set a timeout,

+then default_request_timeout will be ignored. The default

+"default_request_timeout" is set to 0. 0 indicates no default timeout.

+The maximum value that can be set is 65535.

+

+``/proc/sys/fs/fuse/max_request_timeout`` is a read/write file for

+setting/getting the maximum timeout (in seconds) for a fuse server to

+reply to a kernel-issued request. A value greater than 0 automatically opts

+the server into a timeout that will be set to at most "max_request_timeout",

+even if the server did not specify a timeout and default_request_timeout is

+set to 0. If max_request_timeout is greater than 0 and the server set a timeout

+greater than max_request_timeout or default_request_timeout is set to a value

+greater than max_request_timeout, the system will use max_request_timeout as the

+timeout. 0 indicates no max request timeout. The maximum value that can be set

+is 65535.

+

+For timeouts, if the server does not respond to the request by the time

+the set timeout elapses, then the connection to the fuse server will be aborted.

+Please note that the timeouts are not 100% precise (eg you may set 60 seconds but

+the timeout may kick in after 70 seconds). The upper margin of error for the

+timeout is roughly FUSE_TIMEOUT_TIMER_FREQ seconds.

+core_sort_vma

+=============

+

+The default coredump writes VMAs in address order. By setting

+``core_sort_vma`` to 1, VMAs will be written from smallest size

+to largest size. This is known to break at least elfutils, but

+can be handy when dealing with very large (and truncated)

+coredumps where the more useful debugging details are included

+in the smaller VMAs.

+

+

+- defrag_mode

+defrag_mode

+===========

+

+When set to 1, the page allocator tries harder to avoid fragmentation

+and maintain the ability to produce huge pages / higher-order pages.

+

+It is recommended to enable this right after boot, as fragmentation,

+once it occurred, can be long-lasting or even permanent.

+ 19 _/J 524288 userspace used a mutating debug operation in fwctl

+

+ 19) ``J`` if userpace opened /dev/fwctl/* and performed a FWTCL_RPC_DEBUG_WRITE

+ to use the devices debugging features. Device debugging features could

+ cause the device to malfunction in undefined ways.

+found in Documentation/ABI/testing/sysfs-bus-thunderbolt.

+ sudo apt-get install build-essential flex bison yacc