Source string Read only

(itstool) path: sect1/title
Context English State
Boolean; <literal>1</literal> if called from kernel
Determine whether the subject should be allowed to make the specified <citerefentry><refentrytitle>sysctl</refentrytitle><manvolnum>3</manvolnum></citerefentry> transaction.
Label Management Calls
Relabel events occur when a user process has requested that the label on an object be modified. A two-phase update occurs: first, an access control check will be performed to determine if the update is both valid and permitted, and then the update itself is performed via a separate entry point. Relabel entry points typically accept the object, object label reference, and an update label submitted by the process. Memory allocation during relabel is discouraged, as relabel calls are not permitted to fail (failure should be reported earlier in the relabel check).
Userland Architecture
The TrustedBSD MAC Framework includes a number of policy-agnostic elements, including MAC library interfaces for abstractly managing labels, modifications to the system credential management and login libraries to support the assignment of MAC labels to users, and a set of tools to monitor and modify labels on processes, files, and network interfaces. More details on the user architecture will be added to this section in the near future.
APIs for Policy-Agnostic Label Management
The TrustedBSD MAC Framework provides a number of library and system calls permitting applications to manage MAC labels on objects using a policy-agnostic interface. This permits applications to manipulate labels for a variety of policies without being written to support specific policies. These interfaces are used by general-purpose tools such as <citerefentry><refentrytitle>ifconfig</refentrytitle><manvolnum>8</manvolnum></citerefentry>, <citerefentry><refentrytitle>ls</refentrytitle><manvolnum>1</manvolnum></citerefentry> and <citerefentry><refentrytitle>ps</refentrytitle><manvolnum>1</manvolnum></citerefentry> to view labels on network interfaces, files, and processes. The APIs also support MAC management tools including <citerefentry><refentrytitle>getfmac</refentrytitle><manvolnum>8</manvolnum></citerefentry>, <citerefentry><refentrytitle>getpmac</refentrytitle><manvolnum>8</manvolnum></citerefentry>, <citerefentry><refentrytitle>setfmac</refentrytitle><manvolnum>8</manvolnum></citerefentry>, <citerefentry><refentrytitle>setfsmac</refentrytitle><manvolnum>8</manvolnum></citerefentry>, and <citerefentry><refentrytitle>setpmac</refentrytitle><manvolnum>8</manvolnum></citerefentry>. The MAC APIs are documented in <citerefentry><refentrytitle>mac</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
Applications handle MAC labels in two forms: an internalized form used to return and set labels on processes and objects (<literal>mac_t</literal>), and externalized form based on C strings appropriate for storage in configuration files, display to the user, or input from the user. Each MAC label contains a number of elements, each consisting of a name and value pair. Policy modules in the kernel bind to specific names and interpret the values in policy-specific ways. In the externalized string form, labels are represented by a comma-delimited list of name and value pairs separated by the <literal>/</literal> character. Labels may be directly converted to and from text using provided APIs; when retrieving labels from the kernel, internalized label storage must first be prepared for the desired label element set. Typically, this is done in one of two ways: using <citerefentry><refentrytitle>mac_prepare</refentrytitle><manvolnum>3</manvolnum></citerefentry> and an arbitrary list of desired label elements, or one of the variants of the call that loads a default element set from the <citerefentry><refentrytitle>mac.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry> configuration file. Per-object defaults permit application writers to usefully display labels associated with objects without being aware of the policies present in the system.
Currently, direct manipulation of label elements other than by conversion to a text string, string editing, and conversion back to an internalized label is not supported by the MAC library. Such interfaces may be added in the future if they prove necessary for application writers.
Binding of Labels to Users
The standard user context management interface, <citerefentry><refentrytitle>setusercontext</refentrytitle><manvolnum>3</manvolnum></citerefentry>, has been modified to retrieve MAC labels associated with a user's class from <citerefentry><refentrytitle>login.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>. These labels are then set along with other user context when either <literal>LOGIN_SETALL</literal> is specified, or when <literal>LOGIN_SETMAC</literal> is explicitly specified.
It is expected that, in a future version of FreeBSD, the MAC label database will be separated from the <filename>login.conf</filename> user class abstraction, and be maintained in a separate database. However, the <citerefentry><refentrytitle>setusercontext</refentrytitle><manvolnum>3</manvolnum></citerefentry> API should remain the same following such a change.
The TrustedBSD MAC framework permits kernel modules to augment the system security policy in a highly integrated manner. They may do this based on existing object properties, or based on label data that is maintained with the assistance of the MAC framework. The framework is sufficiently flexible to implement a variety of policy types, including information flow security policies such as MLS and Biba, as well as policies based on existing BSD credentials or file protections. Policy authors may wish to consult this documentation as well as existing security modules when implementing a new security service.
Virtual Memory System
<personname> <firstname>Matthew</firstname> <surname>Dillon</surname> </personname> <contrib>Contributed by </contrib>
Management of Physical Memory—<literal>vm_page_t</literal>
<primary>virtual memory</primary>
<primary>physical memory</primary>
<primary><literal>vm_page_t</literal> structure</primary>
Physical memory is managed on a page-by-page basis through the <literal>vm_page_t</literal> structure. Pages of physical memory are categorized through the placement of their respective <literal>vm_page_t</literal> structures on one of several paging queues.
A page can be in a wired, active, inactive, cache, or free state. Except for the wired state, the page is typically placed in a doubly link list queue representing the state that it is in. Wired pages are not placed on any queue.
FreeBSD implements a more involved paging queue for cached and free pages in order to implement page coloring. Each of these states involves multiple queues arranged according to the size of the processor's L1 and L2 caches. When a new page needs to be allocated, FreeBSD attempts to obtain one that is reasonably well aligned from the point of view of the L1 and L2 caches relative to the VM object the page is being allocated for.
Additionally, a page may be held with a reference count or locked with a busy count. The VM system also implements an <quote>ultimate locked</quote> state for a page using the PG_BUSY bit in the page's flags.
In general terms, each of the paging queues operates in a LRU fashion. A page is typically placed in a wired or active state initially. When wired, the page is usually associated with a page table somewhere. The VM system ages the page by scanning pages in a more active paging queue (LRU) in order to move them to a less-active paging queue. Pages that get moved into the cache are still associated with a VM object but are candidates for immediate reuse. Pages in the free queue are truly free. FreeBSD attempts to minimize the number of pages in the free queue, but a certain minimum number of truly free pages must be maintained in order to accommodate page allocation at interrupt time.
If a process attempts to access a page that does not exist in its page table but does exist in one of the paging queues (such as the inactive or cache queues), a relatively inexpensive page reactivation fault occurs which causes the page to be reactivated. If the page does not exist in system memory at all, the process must block while the page is brought in from disk.
<primary>paging queues</primary>
FreeBSD dynamically tunes its paging queues and attempts to maintain reasonable ratios of pages in the various queues as well as attempts to maintain a reasonable breakdown of clean versus dirty pages. The amount of rebalancing that occurs depends on the system's memory load. This rebalancing is implemented by the pageout daemon and involves laundering dirty pages (syncing them with their backing store), noticing when pages are activity referenced (resetting their position in the LRU queues or moving them between queues), migrating pages between queues when the queues are out of balance, and so forth. FreeBSD's VM system is willing to take a reasonable number of reactivation page faults to determine how active or how idle a page actually is. This leads to better decisions being made as to when to launder or swap-out a page.
This translation Translated FreeBSD Doc/books_arch-handbook Conclusion
The following strings have the same context and source.
Translated FreeBSD Doc/articles_leap-seconds Conclusion
Translated FreeBSD Doc/articles_linux-emulation Conclusion
Translated FreeBSD Doc/articles_linux-users Conclusion
Translated FreeBSD Doc/articles_vm-design Conclusion
Translated FreeBSD Doc/books_fdp-primer Conclusion
Translated FreeBSD Doc/articles_building-products Conclusion
Translated FreeBSD Doc/articles_bsdl-gpl Conclusion


No matching activity found.

Browse all component changes


English English
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: sect1/title
Source string location
String age
a year ago
Source string age
a year ago
Translation file
books/arch-handbook.pot, string 1452