#
bd1654ce |
| 21-Dec-2023 |
Mark Johnston <markj@FreeBSD.org> |
freebsd32: Fix error handling for suword32() calls
suword32() returns -1 upon an error, not an errno value.
MFC after: 1 week
|
Revision tags: release/14.0.0 |
|
#
685dc743 |
| 16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
sys: Remove $FreeBSD$: one-line .c pattern
Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/
|
#
4d846d26 |
| 10-May-2023 |
Warner Losh <imp@FreeBSD.org> |
spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD
The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch up to that fact and revert to their recommended match of
spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD
The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch up to that fact and revert to their recommended match of BSD-2-Clause.
Discussed with: pfg MFC After: 3 days Sponsored by: Netflix
show more ...
|
Revision tags: release/13.2.0, release/12.4.0, release/13.1.0 |
|
#
f17ef286 |
| 22-Feb-2022 |
Mateusz Guzik <mjg@FreeBSD.org> |
fd: rename fget*_locked to fget*_noref
This gets rid of the error prone naming where fget_unlocked returns with a ref held, while fget_locked requires a lock but provides nothing in terms of making
fd: rename fget*_locked to fget*_noref
This gets rid of the error prone naming where fget_unlocked returns with a ref held, while fget_locked requires a lock but provides nothing in terms of making sure the file lives past unlock.
No functional changes.
show more ...
|
Revision tags: release/12.3.0 |
|
#
9feff969 |
| 08-Aug-2021 |
Ed Maste <emaste@FreeBSD.org> |
Remove "All Rights Reserved" from FreeBSD Foundation sys/ copyrights
These ones were unambiguous cases where the Foundation was the only listed copyright holder (in the associated license block).
S
Remove "All Rights Reserved" from FreeBSD Foundation sys/ copyrights
These ones were unambiguous cases where the Foundation was the only listed copyright holder (in the associated license block).
Sponsored by: The FreeBSD Foundation
show more ...
|
Revision tags: release/13.0.0, release/12.2.0, release/11.4.0, release/12.1.0 |
|
#
58df81b3 |
| 30-Jul-2019 |
Alan Somers <asomers@FreeBSD.org> |
MFHead @350426
Sponsored by: The FreeBSD Foundation
|
#
91898857 |
| 29-Jul-2019 |
Mark Johnston <markj@FreeBSD.org> |
Avoid relying on header pollution from sys/refcount.h.
MFC after: 3 days Sponsored by: The FreeBSD Foundation
|
Revision tags: release/11.3.0, release/12.0.0, release/11.2.0 |
|
#
7f2d13d6 |
| 27-Nov-2017 |
Pedro F. Giffuni <pfg@FreeBSD.org> |
sys/compat: further adoption of SPDX licensing ID tags.
Mainly focus on files that use BSD 2-Clause license, however the tool I was using misidentified many licenses so this was mostly a manual - er
sys/compat: further adoption of SPDX licensing ID tags.
Mainly focus on files that use BSD 2-Clause license, however the tool I was using misidentified many licenses so this was mostly a manual - error prone - task.
The Software Package Data Exchange (SPDX) group provides a specification to make it easier for automated tools to detect and summarize well known opensource licenses. We are gradually adopting the specification, noting that the tags are considered only advisory and do not, in any way, superceed or replace the license texts.
show more ...
|
Revision tags: release/10.4.0, release/11.1.0, release/11.0.1 |
|
#
8c4282b3 |
| 24-Sep-2016 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r305892 through r306302.
|
Revision tags: release/11.0.0 |
|
#
84a30d33 |
| 19-Sep-2016 |
Konstantin Belousov <kib@FreeBSD.org> |
Add compat32 support for capsicum.
Reviewed by: bapt, emaste Sponsored by: The FreeBSD Foundation MFC after: 2 weeks Differential revision: https://reviews.freebsd.org/D7942
|
Revision tags: release/10.3.0, release/10.2.0, release/10.1.0, release/9.3.0 |
|
#
6cec9cad |
| 03-Jun-2014 |
Peter Grehan <grehan@FreeBSD.org> |
MFC @ r266724
An SVM update will follow this.
|
#
3b8f0845 |
| 28-Apr-2014 |
Simon J. Gerraty <sjg@FreeBSD.org> |
Merge head
|
#
84e51a1b |
| 23-Apr-2014 |
Alan Somers <asomers@FreeBSD.org> |
IFC @264767
|
#
1709ccf9 |
| 29-Mar-2014 |
Martin Matuska <mm@FreeBSD.org> |
Merge head up to r263906.
|
#
4a144410 |
| 16-Mar-2014 |
Robert Watson <rwatson@FreeBSD.org> |
Update kernel inclusions of capability.h to use capsicum.h instead; some further refinement is required as some device drivers intended to be portable over FreeBSD versions rely on __FreeBSD_version
Update kernel inclusions of capability.h to use capsicum.h instead; some further refinement is required as some device drivers intended to be portable over FreeBSD versions rely on __FreeBSD_version to decide whether to include capability.h.
MFC after: 3 weeks
show more ...
|
Revision tags: release/10.0.0 |
|
#
0bfd163f |
| 18-Oct-2013 |
Gleb Smirnoff <glebius@FreeBSD.org> |
Merge head r233826 through r256722.
|
#
3caf0790 |
| 13-Oct-2013 |
Simon J. Gerraty <sjg@FreeBSD.org> |
Merge head@256284
|
#
1ccca3b5 |
| 10-Oct-2013 |
Alan Somers <asomers@FreeBSD.org> |
IFC @256277
Approved by: ken (mentor)
|
#
27650413 |
| 02-Oct-2013 |
Mark Murray <markm@FreeBSD.org> |
MFC - tracking update.
|
Revision tags: release/9.2.0 |
|
#
ef90af83 |
| 20-Sep-2013 |
Peter Grehan <grehan@FreeBSD.org> |
IFC @ r255692
Comment out IA32_MISC_ENABLE MSR access - this doesn't exist on AMD. Need to sort out how arch-specific MSRs will be handled.
|
#
529411c3 |
| 17-Sep-2013 |
Jilles Tjoelker <jilles@FreeBSD.org> |
Disallow cap_enter() in freebsd32 compatibility mode.
The freebsd32 compatibility mode (for running 32-bit binaries on 64-bit kernels) does not currently allow any system calls in capability mode, b
Disallow cap_enter() in freebsd32 compatibility mode.
The freebsd32 compatibility mode (for running 32-bit binaries on 64-bit kernels) does not currently allow any system calls in capability mode, but still permits cap_enter(). As a result, 32-bit binaries on 64-bit kernels that use capability mode do not work (they crash after being disallowed to call sys_exit()). Affected binaries include dhclient and uniq. The latter's crashes cause obscure build failures.
This commit makes freebsd32 cap_enter() fail with [ENOSYS], as if capability mode was not compiled in. Applications deal with this by doing their work without capability mode.
This commit does not fix the uncommon situation where a 64-bit process enters capability mode and then executes a 32-bit binary using fexecve().
This commit should be reverted when allowing the necessary freebsd32 system calls in capability mode.
Reviewed by: pjd Approved by: re (hrs)
show more ...
|
#
47823319 |
| 11-Sep-2013 |
Peter Grehan <grehan@FreeBSD.org> |
IFC @ r255459
|
#
0fbf163e |
| 06-Sep-2013 |
Mark Murray <markm@FreeBSD.org> |
MFC
|
#
d1d01586 |
| 05-Sep-2013 |
Simon J. Gerraty <sjg@FreeBSD.org> |
Merge from head
|
#
7008be5b |
| 05-Sep-2013 |
Pawel Jakub Dawidek <pjd@FreeBSD.org> |
Change the cap_rights_t type from uint64_t to a structure that we can extend in the future in a backward compatible (API and ABI) way.
The cap_rights_t represents capability rights. We used to use o
Change the cap_rights_t type from uint64_t to a structure that we can extend in the future in a backward compatible (API and ABI) way.
The cap_rights_t represents capability rights. We used to use one bit to represent one right, but we are running out of spare bits. Currently the new structure provides place for 114 rights (so 50 more than the previous cap_rights_t), but it is possible to grow the structure to hold at least 285 rights, although we can make it even larger if 285 rights won't be enough.
The structure definition looks like this:
struct cap_rights { uint64_t cr_rights[CAP_RIGHTS_VERSION + 2]; };
The initial CAP_RIGHTS_VERSION is 0.
The top two bits in the first element of the cr_rights[] array contain total number of elements in the array - 2. This means if those two bits are equal to 0, we have 2 array elements.
The top two bits in all remaining array elements should be 0. The next five bits in all array elements contain array index. Only one bit is used and bit position in this five-bits range defines array index. This means there can be at most five array elements in the future.
To define new right the CAPRIGHT() macro must be used. The macro takes two arguments - an array index and a bit to set, eg.
#define CAP_PDKILL CAPRIGHT(1, 0x0000000000000800ULL)
We still support aliases that combine few rights, but the rights have to belong to the same array element, eg:
#define CAP_LOOKUP CAPRIGHT(0, 0x0000000000000400ULL) #define CAP_FCHMOD CAPRIGHT(0, 0x0000000000002000ULL)
#define CAP_FCHMODAT (CAP_FCHMOD | CAP_LOOKUP)
There is new API to manage the new cap_rights_t structure:
cap_rights_t *cap_rights_init(cap_rights_t *rights, ...); void cap_rights_set(cap_rights_t *rights, ...); void cap_rights_clear(cap_rights_t *rights, ...); bool cap_rights_is_set(const cap_rights_t *rights, ...);
bool cap_rights_is_valid(const cap_rights_t *rights); void cap_rights_merge(cap_rights_t *dst, const cap_rights_t *src); void cap_rights_remove(cap_rights_t *dst, const cap_rights_t *src); bool cap_rights_contains(const cap_rights_t *big, const cap_rights_t *little);
Capability rights to the cap_rights_init(), cap_rights_set(), cap_rights_clear() and cap_rights_is_set() functions are provided by separating them with commas, eg:
cap_rights_t rights;
cap_rights_init(&rights, CAP_READ, CAP_WRITE, CAP_FSTAT);
There is no need to terminate the list of rights, as those functions are actually macros that take care of the termination, eg:
#define cap_rights_set(rights, ...) \ __cap_rights_set((rights), __VA_ARGS__, 0ULL) void __cap_rights_set(cap_rights_t *rights, ...);
Thanks to using one bit as an array index we can assert in those functions that there are no two rights belonging to different array elements provided together. For example this is illegal and will be detected, because CAP_LOOKUP belongs to element 0 and CAP_PDKILL to element 1:
cap_rights_init(&rights, CAP_LOOKUP | CAP_PDKILL);
Providing several rights that belongs to the same array's element this way is correct, but is not advised. It should only be used for aliases definition.
This commit also breaks compatibility with some existing Capsicum system calls, but I see no other way to do that. This should be fine as Capsicum is still experimental and this change is not going to 9.x.
Sponsored by: The FreeBSD Foundation
show more ...
|