src/lib/libc/sys/mprotect.2, branch stable/13 FreeBSD source tree Remove $FreeBSD$: one-line nroff pattern 2023-08-23T17:43:32+00:00 Warner Losh imp@FreeBSD.org 2023-08-22T01:32:13+00:00 24115b70d6d614ed7ac5cfc4f51fa9d6cfe8b1b2 Remove /^\.\\"\s*\$FreeBSD\$$\n/ Similar commit in main: (cherry picked from commit b2c76c41be32) 
Remove /^\.\\"\s*\$FreeBSD\$$\n/

Similar commit in main:
(cherry picked from commit b2c76c41be32)
Return ENOTSUP for mmap/mprotect if prot not subset of prot_max 2020-02-26T20:03:43+00:00 Ed Maste emaste@FreeBSD.org 2020-02-26T20:03:43+00:00 acb8858f053814b1a7ad235fd7e5c901dfcc9236 From POSIX, [ENOTSUP] The implementation does not support the combination of accesses requested in the prot argument. This fits the case that prot contains permissions which are not a subset of prot_max. Reviewed by: brooks, cem Relnotes: Yes Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D23843 
From POSIX,

[ENOTSUP]
    The implementation does not support the combination of accesses
    requested in the prot argument.

This fits the case that prot contains permissions which are not a subset
of prot_max.

Reviewed by:	brooks, cem
Relnotes:	Yes
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D23843
mprotect.2: sort errors alphabetically 2020-02-26T18:46:41+00:00 Ed Maste emaste@FreeBSD.org 2020-02-26T18:46:41+00:00 5c6d07fb9cb92eb0e69705f0dec49af9cfdf9b8e Reported by: brooks MFC after: 3 days 
Reported by:	brooks
MFC after:	3 days
Add PROT_MAX to the HISTORY section. 2019-06-20T21:52:30+00:00 Brooks Davis brooks@FreeBSD.org 2019-06-20T21:52:30+00:00 ee37749af6f8738f4c7edf54f80fe61dc71bf130 In the case of mmap(), add a HISTORY section. Mention that mmap() and mprotect()'s documentation predates an implementation. The implementation first saw wide use in 4.3-Reno, but there seems to be no easy way to express that in mdoc so stick with 4.4BSD. Reviewed by: emaste Requested by: cem Sponsored by: DARPA, AFRL Differential Revision: https://reviews.freebsd.org/D20713 
In the case of mmap(), add a HISTORY section.  Mention that mmap() and
mprotect()'s documentation predates an implementation.  The
implementation first saw wide use in 4.3-Reno, but there seems to be no
easy way to express that in mdoc so stick with 4.4BSD.

Reviewed by:	emaste
Requested by:	cem
Sponsored by:	DARPA, AFRL
Differential Revision:	https://reviews.freebsd.org/D20713
Extend mmap/mprotect API to specify the max page protections. 2019-06-20T18:24:16+00:00 Brooks Davis brooks@FreeBSD.org 2019-06-20T18:24:16+00:00 74a1b66cf41de99e2f6ee54f59926c8839a9e10b A new macro PROT_MAX() alters a protection value so it can be OR'd with a regular protection value to specify the maximum permissions. If present, these flags specify the maximum permissions. While these flags are non-portable, they can be used in portable code with simple ifdefs to expand PROT_MAX() to 0. This change allows (e.g.) a region that must be writable during run-time linking or JIT code generation to be made permanently read+execute after writes are complete. This complements W^X protections allowing more precise control by the programmer. This change alters mprotect argument checking and returns an error when unhandled protection flags are set. This differs from POSIX (in that POSIX only specifies an error), but is the documented behavior on Linux and more closely matches historical mmap behavior. In addition to explicit setting of the maximum permissions, an experimental sysctl vm.imply_prot_max causes mmap to assume that the initial permissions requested should be the maximum when the sysctl is set to 1. PROT_NONE mappings are excluded from this for compatibility with rtld and other consumers that use such mappings to reserve address space before mapping contents into part of the reservation. A final version this is expected to provide per-binary and per-process opt-in/out options and this sysctl will go away in its current form. As such it is undocumented. Reviewed by: emaste, kib (prior version), markj Additional suggestions from: alc Obtained from: CheriBSD Sponsored by: DARPA, AFRL Differential Revision: https://reviews.freebsd.org/D18880 
A new macro PROT_MAX() alters a protection value so it can be OR'd with
a regular protection value to specify the maximum permissions.  If
present, these flags specify the maximum permissions.

While these flags are non-portable, they can be used in portable code
with simple ifdefs to expand PROT_MAX() to 0.

This change allows (e.g.) a region that must be writable during run-time
linking or JIT code generation to be made permanently read+execute after
writes are complete.  This complements W^X protections allowing more
precise control by the programmer.

This change alters mprotect argument checking and returns an error when
unhandled protection flags are set.  This differs from POSIX (in that
POSIX only specifies an error), but is the documented behavior on Linux
and more closely matches historical mmap behavior.

In addition to explicit setting of the maximum permissions, an
experimental sysctl vm.imply_prot_max causes mmap to assume that the
initial permissions requested should be the maximum when the sysctl is
set to 1.  PROT_NONE mappings are excluded from this for compatibility
with rtld and other consumers that use such mappings to reserve
address space before mapping contents into part of the reservation.  A
final version this is expected to provide per-binary and per-process
opt-in/out options and this sysctl will go away in its current form.
As such it is undocumented.

Reviewed by:	emaste, kib (prior version), markj
Additional suggestions from:	alc
Obtained from:	CheriBSD
Sponsored by:	DARPA, AFRL
Differential Revision:	https://reviews.freebsd.org/D18880
Renumber copyright clause 4 2017-02-28T23:42:47+00:00 Warner Losh imp@FreeBSD.org 2017-02-28T23:42:47+00:00 fbbd9655e5107c68e4e0146ff22b73d7350475bc Renumber cluase 4 to 3, per what everybody else did when BSD granted them permission to remove clause 3. My insistance on keeping the same numbering for legal reasons is too pedantic, so give up on that point. Submitted by: Jan Schaumann <jschauma@stevens.edu> Pull Request: https://github.com/freebsd/freebsd/pull/96 
Renumber cluase 4 to 3, per what everybody else did when BSD granted
them permission to remove clause 3. My insistance on keeping the same
numbering for legal reasons is too pedantic, so give up on that point.

Submitted by:	Jan Schaumann <jschauma@stevens.edu>
Pull Request:	https://github.com/freebsd/freebsd/pull/96
mprotect(): Change prototype to comply to POSIX. 2016-08-03T06:33:04+00:00 Ed Schouten ed@FreeBSD.org 2016-08-03T06:33:04+00:00 a813fdc6c32b444a11e57e3a44c1cf4af2c99d3d Our mprotect() function seems to take a "const void *" address to the pages whose permissions need to be adjusted. POSIX uses "void *". Simply stick to the POSIX one to prevent us from writing unportable code. PR: 211423 (exp-run) Tested by: antoine@ (Thanks!) 
Our mprotect() function seems to take a "const void *" address to the
pages whose permissions need to be adjusted. POSIX uses "void *". Simply
stick to the POSIX one to prevent us from writing unportable code.

PR:		211423 (exp-run)
Tested by:	antoine@ (Thanks!)
Per Regents of the University of Calfornia letter, remove advertising 2007-01-09T00:28:16+00:00 Warner Losh imp@FreeBSD.org 2007-01-09T00:28:16+00:00 c879ae3536e6d92b8d96c8965c5b05fcb9541520 clause. # If I've done so improperly on a file, please let me know. 
clause.

# If I've done so improperly on a file, please let me know.
mdoc(7) police: markup laundry. 2003-02-23T01:47:49+00:00 Ruslan Ermilov ru@FreeBSD.org 2003-02-23T01:47:49+00:00 522ccf3f353a439b7938a4f10adfab7d912210a2 






Document protection bits.
2002-12-23T19:25:03+00:00

Tom Rhodes
trhodes@FreeBSD.org

2002-12-23T19:25:03+00:00

3c094e54a7a12ec850d0e4eb39d1de8ca8c6db84

PR:		46252
Submitted by:	Jeroen Ruigrok van der Werven <asmodai@wxs.nl>





PR:		46252
Submitted by:	Jeroen Ruigrok van der Werven <asmodai@wxs.nl>