aboutsummaryrefslogtreecommitdiff
path: root/sys
Commit message (Collapse)AuthorAgeFilesLines
* LinuxKPi: idr: use macros for lock idr lock operationsBjoern A. Zeeb2026-05-301-30/+37
| | | | | | | | | | | | | Our idr implementation is using a mtx lock which in the past has already caused problems (613723bac219c). In order to make it easier to tackle the problem start by factoring out all the operations related to the idr->lock into macros as we have often done in other parts of code as well. Sponsored by: The FreeBSD Foundation MFC after: 3 days Reviewed by: wulf, emaste Differential Revision: https://reviews.freebsd.org/D55392
* LinuxKPI: 802.11 suspend/resume: fix the is_pci_dev checkBjoern A. Zeeb2026-05-301-1/+2
| | | | | | | | | | | | | | | | | | | | Shortly before I committed the works from a year ago, jhb added a function ("is_pci_device") so that the check against the devclass does not have to be coded in every driver. Use this instead in main (and stable/15 in case the works get MFCed). At the same time this fixes the check (the old one was wrong) as we attach to the LinuxKPI 802.11 driver, e.g., iwlwifi and thus we need to check the parent of the parent and not just the parent to be of the devclass "pci" in the identify bus function. The was the first error. The second was (and this is why it worked) that we checked for == instead of != and so the wrong check became true again. Discussed with: jhb Fixes: 11d69a4558de ("LinuxKPI: 802.11: add support for s/r") MFC after: 3 days X-MFC after: ffcf5e356644 ("pci: Add is_pci_device helper function") Sponsored by: The FreeBSD Foundation
* rtwn/usb: add ID for D-Link DWA-121 rev B1 to rtwn RTL8188EUBjoern A. Zeeb2026-05-302-0/+2
| | | | | | | | | | Add the device ID to the usbdevs table in order to be able to use it in the rtwn/usb driver for the RTL8188EU attachment. (I adjusted the name to B1 compared to the original submission) PR: 291839 MFC after: 3 days
* linux: Add support for PR_SET_VMA to prctl(2)Pawel Biernacki2026-05-302-0/+9
| | | | | | Implement dummy support for PR_SET_VMA with PR_SET_VMA_ANON_NAME in prctl(2). This prevents applications from receiving EINVAL when attempting to name anonymous memory regions.
* imgact_elf: add sysctl kern.elfXX.phnums for the number of program headersKonstantin Belousov2026-05-301-10/+12
| | | | | | | | | | that are accepted in the activated image or interpreter. Requested by: jhb Reviewed by: markj Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D57328
* edk2: enable static asserts for *INT64 alignmentAhmad Khalifa2026-05-301-2/+0
| | | | | | The ia32 loader is now built with -malign-double, so these should pass. Differential Revision: https://reviews.freebsd.org/D55386
* netlink/route: extend pre-2.6.19 Linux compat shim to del/getrouteOlivier Cochard2026-05-291-3/+11
| | | | | | | | | | | | | | | | | | Commit f34aca55adef ("netlink/route: provide pre-2.6.19 Linux compat shim", 2024-06) fixed the partial fix for net/bird2 on the netlink path by mapping the legacy 8-bit struct rtmsg::rtm_table field onto the modern 32-bit RTA_TABLE attribute when the latter is absent. That fix, however, was only applied to rtnl_handle_newroute. The two sibling handlers: rtnl_handle_delroute and rtnl_handle_getroute were left looking at attrs.rta_table directly. They are reachable from exactly the same client (bird, in its netlink scan path), so any FIB number that fits in 8 bits silently maps to RT_TABLE_UNSPEC in those handlers. Reviewed by: melifaro (previous version) Approved by: emaste MFC after: 1 week Sponsored by: Netflix
* netlink: Check permissions for interface flag changesEd Maste2026-05-291-1/+10
| | | | | | Reviewed by: pouria, melifaro Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D57332
* netlink: Use early exit pattern in _nl_modify_ifp_genericEd Maste2026-05-291-28/+25
| | | | | | | | No functional change. Reviewed by: pouria, melifaro Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D57349
* syscalls.master: Allow clock_nanosleep in capability modeEd Maste2026-05-291-1/+1
| | | | | | | | | | It is akin to nanosleep(2) and does not access global namespaces. It should be permitted in capability mode. Reviewed by: vangyzen Fixes: 3f8455b0905a ("Add clock_nanosleep()") Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D57343
* sys: Renumber MTE SEGV codesAndrew Turner2026-05-291-2/+2
| | | | | | | | Some third party software expects these to not conflict. As the MTE support isn't fully in the tree, and these values aren't in a release we can renumber them without any backwards compatibility issues. Sponsored by: Arm Ltd
* MAC/do: Update copyrightOlivier Certner2026-05-291-3/+3
| | | | | | | | | | | | | | | Update years for the Foundation. While here, remove the initial '/*-' which has been useless for a long time. While here, add a missing space on bapt@'s copyright line (approved by him). Reviewed by: bapt MFC after: 1 month Sponsored by: The FreeBSD Foundation Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/38
* MAC/do: Do not skip blanks when parsing executable pathsOlivier Certner2026-05-291-1/+1
| | | | | | | | | | | | | | | | The kind of tolerance we apply to parsing rules, whose format we have defined, cannot be applied to paths since blank characters are allowed there. There is still the limitation that no escape character is currently supported, and so it is not possible to configure a path having a ':' character. Reviewed by: bapt Fixes: 9818224174c4 ("MAC/do: Executable paths feature (GSoC 2025's final state)") MFC after: 1 month Sponsored by: The FreeBSD Foundation Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/38
* MAC/do: Serialize installing/modifying some jail's configurationOlivier Certner2026-05-291-23/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | See the immediately preceding commit for explanations on what this is fixing. When setting 'mac.do' to 'inherit' on a jail with 'mac.do.rules' and 'mac.do.exec_paths' also specified in the same call, ensure that the check that these passed parameters are the same as those to be inherited is atomic with respect to enabling the inheritance (i.e., removing the jail's 'struct conf' object). (See previous commit "MAC/do: Fix the recent logic to set jail parameters, make it more tolerant" as for why this check exists.) Because we currently only modify a single configuration object per transaction, we introduce the parse_and_commit_conf() wrapper around parse_and_set_conf() to remove duplicated code that would ensue from calling the latter directly, namely, releasing the 'mac_do_rwl' lock and freeing the old configuration object (if any). Taking the 'mac_do_rwl' lock for writing as a way to freeze all accesses to mac_do(4) configurations was deemed too thin an operation to be worth wrapping. Reviewed by: bapt (older version) Fixes: 9818224174c4 ("MAC/do: Executable paths feature (GSoC 2025's final state)") MFC after: 1 month Sponsored by: The FreeBSD Foundation Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/38
* MAC/do: Support for atomically modifying configurationsOlivier Certner2026-05-291-15/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As mentioned in previous commits "MAC/do: parse_and_set_conf(): Require the model configuration" and "MAC/do: Sequential consistency for configuration retrieval", the introduction of the "executable path" feature, more fundamentally, the fact that there is now more than one per-jail parameter and that parameters can be independently modified or copied, causes an atomicity problem in case of concurrent accesses to of a jail's applicable configuration. Partially modifying a configuration is indeed akin to a read-modify-write operation, where the read is either to the current or an inherited configuration. More precisely, once pointed to by a jail, a configuration object is immutable, and changing the jail's configuration means making the jail point to another configuration object. To change a jail's configuration, a new configuration object is thus built, and if only some parameters have been explicitly specified, those that have not been are set by copying the corresponding values from an existing configuration object (in case of partial modification of the existing configuration, from the original configuration object that is going to be replaced; in case of breakage of inheritance or at jail creation, from the applicable configuration object, which is on an ancestor jail). This process is not immune to concurrent modifications because nothing prevents changes of configurations between reading existing values and setting the new configuration. Thus, some other thread could change the value of a parameter after a copy of it has been made into the new object but before that copy is actually installed, which effectively will erase the other thread's modification. To avoid this, we introduce support for serializing configuration changes on a given jail. To this end, we move the jail climbing process from find_conf() into find_conf_locked(), and make the former call the latter in a read-locked section. Similarly, we isolate setting a configuration in the new set_conf_locked() function, and make set_conf() call it inside a write-locked section. The new *_unlocked() variants make it possible to prevent any configuration access between determining and reading an applicable configuration, computing from it a new configuration object and finally setting it, by holding a write lock over the whole process (there is a trade-off here, as read-mostly locks cannot be upgraded), effectively making it atomic and realizing full sequential consistency of configuration changes. Also, the 'mac_do_rm' global read-mostly lock is made sleepable so that it can be write-locked over sysctl_handle*() functions or memory allocations (eases implementation, at the expense of a potential loss of concurrency which is most probably irrelevant). No functional change (intended) at this point. Reviewed by: bapt Fixes: 9818224174c4 ("MAC/do: Executable paths feature (GSoC 2025's final state)") MFC after: 1 month Sponsored by: The FreeBSD Foundation Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/38
* MAC/do: Sequential consistency for configuration retrievalOlivier Certner2026-05-291-48/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since the inception of mac_do(4), find_conf(), used to retrieve the applicable configuration, has been weakly consistent with respect to concurrent modifications to configuration inheritance that influence its result (and it has been sequentially consistent with respect to other configuration modifications, which the initial executable paths feature and introduction of implicit parameters broke and which will be fixed in a subsequent commit). Indeed, find_conf() climbs the jail tree to find an applicable configuration, which is not an atomic operation. It examines the current jail's configuration pointer for each browsed jail, which does not prevent concurrent modifications of the configuration pointer for jails below or above it. Modifications above the current jail are not a problem, since if climbing needs to continue (i.e., the current jail inherits), these modifications will be seen if performed before that check (and may or may not be seen if performed after that check). However, modifications below the current jail impair sequential consistency, because they could be done before other modifications at the current jail or higher up, and the latter could still be picked up by the rest of the climb, effectively ignoring that the former should have blocked the climb earlier, making them look as if they had happened after for the climbing thread. As a concrete example of this situation, let's examine a scenario where some jail A is the parent of some jail B, and B inherits its configuration from A. An administrator may want to relax the rules only for jail A but not B. To this end, he first copies the current rules on B over to A and then relaxes the rules on A. He can intuitively and reasonably expect that changing B's rules first will prevent A's relaxed rules to leak to threads in B. Unfortunately, that is not the case: As explained in the previous paragraph, there can be a time window where threads from B can still pick up A's new configuration just after it has been installed. This arguably makes changing inheritance in mac_do(4) in a fully secure fashion almost impossible. If preserving fine-grained locking of prisons, we could prevent this problem by having find_conf(), once it has climbed to a non-NULL pointer (actual, non-inherited configuration), do another climb to check that it can reach the same configuration on the same jail again. If the new climb gives another pointer or jail, it could make it the new candidate and do a climb check again until the situation stabilizes. A climb check detects whether changes in jails below that of the candidate configuration object happened, catching in particular such changes that happened before changes to the candidate object. However, that process alone would still be subject to ABA problems, and we would additionally need to tag each prison with some modification timestamp (global, or local but necessitating allocating memory during the check) to fix them. In the end, we considered this direction to be unnecessarily complex, given that configuration changes are to be rare events and most uses will just be configuration determination. Consequently, switch protecting jail configurations with a single read-mostly lock. While here, adapt set_conf() to accept NULL as the new configuration object, and have remove_conf() call it, which removes duplicated code. While here, add a comment explaining why we do not need to take any more locks when climbing the jail tree. Reviewed by: bapt MFC after: 1 month Sponsored by: The FreeBSD Foundation Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/38
* MAC/do: Comment to explain the main invariant for configurationsOlivier Certner2026-05-291-0/+5
| | | | | | | | | | | | Once visible, configuration structures must *never* change. Spell that out in a comment to help future readers/contributors understand the design. Reviewed by: bapt MFC after: 1 month Sponsored by: The FreeBSD Foundation Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/38
* MAC/do: Allocate only one default configurationOlivier Certner2026-05-291-12/+12
| | | | | | | | | | | | When mac_do(4) is loaded, all jails get the same default configuration (disabled, with only one allowed executable path: '/usr/bin/mdo'). Share it between all jails instead of creating a separate copy for each. Reviewed by: bapt Fixes: 9818224174c4 ("MAC/do: Executable paths feature (GSoC 2025's final state)") MFC after: 1 month Sponsored by: The FreeBSD Foundation Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/38
* MAC/do: Visually separate some file sectionsOlivier Certner2026-05-291-0/+2
| | | | | | | | | | | With additional empty lines. No functional change (intended). Reviewed by: bapt MFC after: 1 month Sponsored by: The FreeBSD Foundation Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/38
* MAC/do: Fix reporting of "mac.do" post-"executable paths"Olivier Certner2026-05-291-3/+2
| | | | | | | | | | | In mac_do_jail_get(), computation of 'jsys' had not been updated to take into account executable paths. Reviewed by: bapt Fixes: 9818224174c4 ("MAC/do: Executable paths feature (GSoC 2025's final state)") MFC after: 1 month Sponsored by: The FreeBSD Foundation Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/38
* MAC/do: Configuration: Fix default values: Remove jail creation methodOlivier Certner2026-05-291-14/+6
| | | | | | | | | | | | | | | | | | | | | | | | | mac_do_jail_create() would create a default configuration on the just-created jail, erroneously causing mac_do_jail_set() to then retrieve it and use it as a model when determining the default values for not-specified parameters, instead of using the configuration applicable to the parent jail. Setting a default configuration in mac_do_jail_create() had been done as a kind of defensive measure to prevent a created jail not to have a configuration (effectively making it inherit from an ancestor jail, which is a security hazard except if explicitly requested). However, this measure was never really effective (osd_jail_call(PR_METHOD_CREATE) in kern_jail_set() calls the PR_PETHOD_CREATE methods in an unspecified order, and stops at the first error), so we are forced to rely in any case on the fact that an error in a PR_METHOD_CREATE or PR_METHOD_SET method leads to stopping the jail creation process (which is the case today; see kern_jail_set()). Reviewed by: bapt Fixes: 9818224174c4 ("MAC/do: Executable paths feature (GSoC 2025's final state)") MFC after: 1 month Sponsored by: The FreeBSD Foundation Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/38
* MAC/do: Fix the recent logic to set jail parameters, make it more tolerantOlivier Certner2026-05-291-61/+140
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The logic introduced in the initial commit for the "executable paths" feature did not match the specification we discussed in that specifying an empty value (for rules or executable paths) on "mac.do" being "new" would be treated as an absence of value and trigger a copy from the currently applicable configuration, instead of being an override that deactivates mac_do(4) in the jail. Fix that by distinguishing both cases. More generally, a non-explicitly specified parameter is set to the same value it has in the currently applicable configuration (that of the closest ancestor jail that has one; 'prison0' (the host) always has one), with an exception in the disable case. On disable (explicit: "mac.do" to "disable", implicit: no parameters passed, or at least one is empty), now accept parameters with a non-empty value as long as at least one of them is empty (which alone is enough to disable mac_do(4)). If no parameters are passed, both are copied from the currently applicable configuration; if none of them is empty, then the rules are emptied to effectively disable mac_do(4) (see the inline comment as to why this was chosen). On explicit enable ("mac.do" to "enable"), allow not specifying any of the rules and executable paths, in which case both are copied from the currently applicable configuration (consistently with what is done when only one is missing). Note that, as mentioned above, not specifying any of them by default still resolves to disabling mac_do(4) (i.e., on no explicit "mac.do" parameter). On (explicit) inheritance, allow specifying non-empty parameters, provided they match the values we are going to inherit. This enables re-applying jail parameters' reported values verbatim to the current jail (idempotence) or, e.g., to some sibling jail. (While here, make some existing code easier to read by leveraging is_null_or_empty().) Reviewed by: bapt Fixes: 9818224174c4 ("MAC/do: Executable paths feature (GSoC 2025's final state)") MFC after: 1 month Sponsored by: The FreeBSD Foundation Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/38
* MAC/do: Constify is_null_or_empty()Olivier Certner2026-05-291-1/+1
| | | | | | | Reviewed by: bapt MFC after: 1 month Sponsored by: The FreeBSD Foundation Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/38
* MAC/do: Fix obsolete wording in a comment ("ascendant" => "ancestor")Olivier Certner2026-05-291-1/+1
| | | | | | | Reviewed by: bapt MFC after: 1 month Sponsored by: The FreeBSD Foundation Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/38
* MAC/do: parse_and_set_conf(): Require the model configurationOlivier Certner2026-05-291-28/+38
| | | | | | | | | | | | | | | | | | | | | | | | | This change is a prerequisite for the next change in caller mac_do_jail_set(), which for semantic correctness needs to rely on a stable model configuration. The two other callers already call find_conf() to retrieve the applicable configuration, so for these a second call to find_conf() can be saved. However, this does not fix (actually, makes slightly worse) an atomicity problem when multiple threads concurrently change some jail's configuration (or the configuration inherited by a jail), which has existed since the introduction of executable paths due to being able to change only rules or executable paths independently (and the possibility of not specifying them and having them copied from the currently applicable configuration). Before tackling it in later commits, we first focus on fixing the semantics of configuration changes in the very next patches. Reviewed by: bapt MFC after: 1 month Sponsored by: The FreeBSD Foundation Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/38
* MAC/do: parse_and_set_conf(): Obey empty parameters; Add docOlivier Certner2026-05-291-14/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | parse_and_set_conf() is meant to be used in all situations when there is a need to set or modify some jail's MAC/do configuration. This entails passing the information of whether some parameter was explicitly specified. For example, an administrator setting/modifying jail parameters may not specify executable paths but only rules, in which case the executable paths value is copied from the currently-applicable configuration. The sysctl(8) knobs case always leverages this feature, since setting a knob changes one parameter at a time. Currently, a NULL or empty string argument is treated as a non-specified parameter. This causes a bug where disabling MAC/do in a jail does not actually work because, to this end, parse_and_set_conf() is passed an empty string which it then interprets as a request to copy the currently applicable configuration's value, which may well not be empty. Fix this problem by only treating NULL as a marker for a non-specified parameter, in accordance with the original design for this function. While here, write some documentation to explain the interface. While here, remove the original herald comment for parse_and_set_rules(), which was inadvertently pushed apart from the replacing parse_and_set_conf(). Reviewed by: bapt Fixes: 9818224174c4 ("MAC/do: Executable paths feature (GSoC 2025's final state)") MFC after: 1 month Sponsored by: The FreeBSD Foundation Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/38
* MAC/do: clone_rules(): Readability improvements, constificationOlivier Certner2026-05-291-11/+13
| | | | | | | | | | | | Constify in order to let the compiler check that source and destination arguments are passed in the proper order in the different calls. No functional change (intended). Reviewed by: bapt MFC after: 1 month Sponsored by: The FreeBSD Foundation Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/38
* MAC/do: Remove superfluous configuration initializationOlivier Certner2026-05-291-10/+24
| | | | | | | | | | | | Configuration objects would be initialized (zeroed, and some STAILQ_INIT() called) multiple times. Make sure they are so only once, and add assertions to check that this is actually the case for functions that expect it. Reviewed by: bapt MFC after: 1 month Sponsored by: The FreeBSD Foundation Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/38
* MAC/do: Move static assertions on constants close to their definitionsOlivier Certner2026-05-291-4/+6
| | | | | | | | | And document more clearly their purpose. Reviewed by: bapt MFC after: 1 month Sponsored by: The FreeBSD Foundation Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/38
* MAC/do: Constify clone_rules() and clone_exec_paths()'s source argumentOlivier Certner2026-05-291-2/+3
| | | | | | | | | Defensive programming. Reviewed by: bapt MFC after: 1 month Sponsored by: The FreeBSD Foundation Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/38
* MAC/do: Fix releasing a nonexistent reference on configuration parsing errorOlivier Certner2026-05-291-6/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On parsing error, parse_and_set_conf(), introduced with the recent "executable paths" feature, has been calling drop_conf() on the being-built configuration. However, that configuration structure is allocated through alloc_conf(), which does not grab a reference. Calling drop_conf() on it, which releases a reference, is thus erroneous, and causes the underlying counter to saturate, translating into a memory leak. To fix this bug, make alloc_conf() grab a reference on the newly-created 'struct conf', and rename it to new_conf() to be more in line with what it does. Keep set_conf() as is, i.e., grabbing an additional reference on behalf of the jail that is going to hold the configuration. Consequently, make sure that callers of alloc_conf() unconditionally drop the reference acquired by the latter before returning (i.e., even if set_conf() has been called). While here, since hold_conf() is always used to obtain additional references on a configuration (new_conf() does not use it, instead directly setting the use count), add an assertion that it is never used on a configuration that has no references at all (which indicates that the configuration has been destroyed). These changes generally simplify the lifecycle of configurations, reducing the probability of re-introducing reference mismatches (at the expense of slightly more reference counting operations, but performance does not matter here). Reviewed by: bapt Fixes: 9818224174c4 ("MAC/do: Executable paths feature (GSoC 2025's final state)") MFC after: 1 month Sponsored by: The FreeBSD Foundation Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/38
* MAC/do: find_conf(): Return configuration with a true referenceOlivier Certner2026-05-291-43/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In addition to the applicable configuration, find_conf() was returning a pointer to the actual jail holding the configuration object, with that jail's mutex locked in order to ensure liveness of the returned configuration (if we wouldn't, a concurrent thread modifying the jail's configuration could destroy this configuration object underneath us). But: 1. Ensuring configuration stability by owning the holding jail's mutex requires callers to either keep that mutex locked for a longer period of time than just accessing the corresponding 'struct prison' (in general, bad for concurrency with other operations involving jails) or to perform an additional dance to acquire a real reference in case the jail's mutex, for some reason (in general, LORs or acquiring a sleepable lock) must be dropped before use. 2. Most code does not actually need to know which jail holds the applicable configuration but for unlocking the jail's mutex. Having to deal with the jail holding the configuration can cause confusion about which jail (the current one, or the one holding the configuration) must be used (and actually did in the very initial version of MAC/do, which had a serious flaw as a consequence). So, do not keep a lock on the holding jail. Instead, ensure configuration stability by always acquiring a true reference from the start and passing it to the caller. Those callers not doing the dance mentioned above now need to free it when finished (but this need replaces the one to unlock the prison). Additionally, only return the holding jail if explicitly requested by the caller. mac_do_jail_get() is currently the only caller that needs it, in order to be able to reliably report if the configuration is inherited. Reviewed by: bapt MFC after: 1 month Sponsored by: The FreeBSD Foundation Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/38
* MAC/do: Move hold_conf() and drop_conf() earlierOlivier Certner2026-05-291-15/+15
| | | | | | | | | This is in preparation for using hold_conf() in find_conf(). Reviewed by: bapt MFC after: 1 month Sponsored by: The FreeBSD Foundation Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/38
* MAC/do: find_conf(): Turn an MPASS() into a KASSERT()Olivier Certner2026-05-291-1/+9
| | | | | | | | | | | | | | | | Turn the pre-existing comment into an assertion message, with an update following the introduction of the "executable paths" feature. Explain in a comment why this situation cannot happen. Without INVARIANTS, such a situation would cause an immediate panic() (NULL is dereferenced in the next iteration of the loop), so leave the check under INVARIANTS only. Reviewed by: bapt MFC after: 1 month Sponsored by: The FreeBSD Foundation Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/38
* MAC/do: Rename size constants/variables to clear confusion with string lengthsOlivier Certner2026-05-291-34/+34
| | | | | | | | | | | | | | | | | These constants represent buffer sizes in bytes, not string lengths. While here, move MAX in EXEC_PATHS_MAXLEN at start, like the other constants. While here, fix the prefix of the old MAC_RULE_STRING_LEN accordingly. No functional change. Reviewed by: bapt Fixes: 8aac90f18aef ("mac_do: add a new MAC/do policy and mdo(1) utility") Fixes: 9818224174c4 ("MAC/do: Executable paths feature (GSoC 2025's final state)") MFC after: 1 month Sponsored by: The FreeBSD Foundation Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/38
* MAC/do: Executable paths: Accept an empty stringOlivier Certner2026-05-291-6/+0
| | | | | | | | | | | | This effectively allows to disable mac_do(4) by setting the executable paths to an empty string, realizing a symmetry with rules to be leveraged in subsequent commits. Reviewed by: bapt Fixes: 9818224174c4 ("MAC/do: Executable paths feature (GSoC 2025's final state)") MFC after: 1 month Sponsored by: The FreeBSD Foundation Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/38
* MAC/do: Document and assert when parse error objects must be builtOlivier Certner2026-05-291-32/+50
| | | | | | | | | | | | | | | | | | | | | | | | The invariant is that parse_*() functions must create a parse error object and return it through their 'parse_error' argument if and only if they return an error code (non-zero). Add assertions checking this invariant in various places, and in particular in the new parse_exec_paths(), to be future proof. Change the contract of parse_and_set_conf() so that the caller is required to pass a NULL '*parse_error'. Remove useless resetting of '*parse_error' to NULL. While here, remove a test that is always true thanks to this invariant and that was recently introduced with the "executable paths" feature. No functional change intended. Reviewed by: bapt MFC after: 1 month Sponsored by: The FreeBSD Foundation Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/38
* MAC/do: check_proc(): Remove a superfluous 'if'Olivier Certner2026-05-291-6/+5
| | | | | | | | | No functional change (intended). Reviewed by: bapt MFC after: 1 month Sponsored by: The FreeBSD Foundation Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/38
* MAC/do: Expand "conf" to "configuration" in a panic message on INVARIANTSOlivier Certner2026-05-291-2/+2
| | | | | | | | | | No functional change. Reviewed by: bapt Fixes: 9818224174c4 ("MAC/do: Executable paths feature (GSoC 2025's final state)") MFC after: 1 month Sponsored by: The FreeBSD Foundation Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/38
* MAC/do: Fix recently-introduced commentsOlivier Certner2026-05-291-14/+25
| | | | | | | | Reviewed by: bapt Fixes: 9818224174c4 ("MAC/do: Executable paths feature (GSoC 2025's final state)") MFC after: 1 month Sponsored by: The FreeBSD Foundation Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/38
* MAC/do: Make it style(9) compliant againOlivier Certner2026-05-291-70/+96
| | | | | | | | | | | | | | | Fix too long lines, declarations not at head of block, improper indentation and superfluous whitespace coming from the previous commit introducing the configurable executable paths feature. While here, fix some older improper comment formatting. Reviewed by: bapt Fixes: 6c3def74e2de ("MAC/do: Support multiple users and groups as single rule's targets") Fixes: 9818224174c4 ("MAC/do: Executable paths feature (GSoC 2025's final state)") MFC after: 1 month Sponsored by: The FreeBSD Foundation Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/38
* MAC/do: Update copyrightOlivier Certner2026-05-291-0/+1
| | | | | | | | | | Add Kushagra to account for the commit adding the "executable paths" feature. Reviewed by: bapt MFC after: 1 month Sponsored by: The FreeBSD Foundation Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/38
* MAC/do: Executable paths feature (GSoC 2025's final state)Kushagra Srivastava2026-05-291-159/+422
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | By design, mac_do(4) only authorizes credentials change requests if they are issued by a process spawned from '/usr/bin/mdo'. The executable paths feature introduces some flexibility by allowing to change that path, thus allowing another executable to make requests, and to use multiple such paths (up to 8 in the current implementation). Its purpose is to enable thin jails scenarios where mdo(1) may not be at its canonical path ('/usr/bin/mdo') and to allow experimenting with other userland programs leveraging setcred(2). Configuration of executable paths is per-jail and intentionally works completely similarly with rules. It is accessible from within a jail through the 'security.mac.do.exec_paths' sysctl knob and from outside a jail through the 'mac.do.exec_paths' jail parameter. This commit groups the verbatim changes of the following commits that Kushagra Srivastava, our GSoC 2025 student, created in his GitHub repository (https://github.com/thesynthax/freebsd-src), branch 'task/exec-paths-refactor': mac_do(4): Complete refactor of allowed executable paths feature mac_do(4): Fixed changing security.mac.do.* knobs in inheritance mode mac_do(4): Debugging rules and exec_paths leak on destroy mac_do(4): Deep copy rules mac_do(4): Fixed leak mac_do(4): fixed various bugs, structs inlined, leaks remain mac_do(4): MAC/do working in jail, leaks decreased mac_do(4): MAC/do fixed, works in host and jails, leaks removed mac_do(4): style Frozen log for these commits: https://github.com/OlCe2/freebsd-src/compare/main...14fdc49fb29265fac5d0daf95a13d0dce325c951. The corresponding pull request is at: https://github.com/OlCe2/freebsd-src/pull/2. The GSoC's final state of this code still has a number of problems that are fixed in subsequent commits. It is however committed separately to clearly delineate Kushagra's work. Reviewed by: olce (amendments to come, see above) MFC after: 1 month Relnotes: yes Sponsored by: Google LLC (GSoC 2025) Sponsored by: The FreeBSD Foundation (review, commit) Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/38
* bnxt: Fix build / load error for bnxt(4) in kernels without PCI_IOVAndrew Gallatin2026-05-293-6/+39
| | | | | | | | | | | This change removes the hard-forcing of PCI_IOV and adds shims to allow the driver to compile and work when the kernel is missing PCI_IOV support. Fixes: 7c450d1127c7 Reviewed by: sumit.saxena_broadcom.com Differential Revision: https://reviews.freebsd.org/D57300 Sponsored by: Netflix
* imgact_elf: read program headers if not contained in the first pageKonstantin Belousov2026-05-281-29/+62
| | | | | | | | | PR: 295629 Reviewed by: markj Tested by: Alex S <iwtcex@gmail.com> Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D57294
* image activators: pass the current threadKonstantin Belousov2026-05-283-20/+18
| | | | | | | | Reviewed by: markj Tested by: Alex S <iwtcex@gmail.com> Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D57294
* rtnetlink: Fix weight overflow in RTA_MULTIPATHPouria Mousavizadeh Tehrani2026-05-281-2/+3
| | | | | | | | | | If the weight value is larger than 8 bits, set it to the maximum. Also, only send RTA_WEIGHT if its value is not the default. This reduces message size and matches the behavior of non-multipath routes. Reviewed by: emaste, markj Differential Revision: https://reviews.freebsd.org/D57266
* LinuxKPI: migrate key data access to functionsAdrian Chadd2026-05-281-9/+15
| | | | | | | | | | | | * Migrate the k->wk_key and k->wk_keylen access to the new crypto methods in net80211 * don't use ic_miclen, use the tx/rx mic len methods * don't use wk_txmic and wk_rxmic, use the tx/rx mic data methods This is in preparation to support GTK/IGTK keys and > 128 bit keys. Reviewed by: bz Differential Revision: https://reviews.freebsd.org/D54485
* linuxulator: return EBADF for O_PATH mmap()YAO, Xin2026-05-281-0/+4
| | | | | | | | | | This fixes LTP open13, which expects O_PATH mmap() to fail with EBADF, but FreeBSD returned EACCES. Signed-off-by: YAO, Xin <mr.yaoxin@outlook.com> PR: 295571 Reviewed by: kib Pull-Request: https://github.com/freebsd/freebsd-src/pull/2233
* cxgbe(4): Improvements to the slow interrupt handlerNavdeep Parhar2026-05-282-188/+1648
| | | | | | | | | | | * Add a flag to indicate that an INT_CAUSE should not be cleared automatically in the generic handler. This is to ensure correct operation of some INT_CAUSEs that are related to each other and must be cleared in a certain order. * Add decode for many more INT_CAUSE registers. MFC after: 1 week Sponsored by: Chelsio Communications
generated by cgit v1.3 (git 2.53.0) at 2026-09-06 23:18:52 +0000