FORTIFY_SOURCE feature of libssp, thus checking the size of arguments to
various string and memory copy and set functions (as well as a few system
calls and other miscellany) where known at function entry. RedHat has
evidently built all "core system packages" with this option for some time.
This option should be used at the top of Makefiles (or Makefile.inc where
this is used for subdirectories) but after any setting of LIB.
This is only useful for userland code, and cannot be used in libc or in
any code which includes the libc internals, because it overrides certain
libc functions with macros. Some effort has been made to make USE_FORT=yes
work correctly for a full-system build by having the bsd.sys.mk logic
disable the feature where it should not be used (libc, libssp iteself,
the kernel) but no attempt has been made to build the entire system with
USE_FORT and doing so will doubtless expose numerous bugs and misfeatures.
Adjust the system build so that all programs and libraries that are setuid,
directly handle network data (including serial comm data), perform
authentication, or appear likely to have (or have a history of having)
data-driven bugs (e.g. file(1)) are built with USE_FORT=yes by default,
with the exception of libc, which cannot use USE_FORT and thus uses
only USE_SSP by default. Tested on i386 with no ill results; USE_FORT=no
per-directory or in a system build will disable if desired.
was developed as part of Google's Summer of Code 2005 program. This
change adds the kernel code, the mount_tmpfs utility, a regression test
suite and does all other related changes to integrate these.
The file-system is still *experimental*. Therefore, it is disabled by
default in all kernels. However, as typically done, a commented-out
entry is added in them to ease its setup.
Note that I haven't commited the required mountd(8) changes to be able
to export tmpfs file-systems because NFS support is still very unstable
and because, before enabling it, I'd like to do some other changes.
OK'ed by my project mentor, William Studenmund (wrstuden@).
define and use vm_map_set{min,max}() for modifying these values.
remove the {min,max}_offset aliases for these vm_map fields to be more
namespace-friendly. PR 26475.
definition. Since we're now passing it into pmap.c which is already
compiled that way, it would be nice if it was the right size.
Also, fix a memset bug that caused a segmentation fault when printing
the kernel's vm_map.
-A address Dumps the vm_amap structure found at address.
-E address Dumps the vm_map_entry structure found at address.
-S address Dumps the vmspace structure found at address.
-V address Dumps the vm_map structure found at address.
This required reorganizing the code a little, which led to some
cleanup (yay!). These new methods are executed without any extra
privileges, so you need read access on /dev/mem or on the kernel core
into which you are digging.
This should be useful for, eg, examining amaps are corrupt when being
destroyed, which can cause a kernel panic (and, hence, are no longer
connected to a map entry, or the map entry is no longer connected to a
vm_map/vmspace).
The options in the man page have also been reorganized.
am_bckptr, am_slots, and am_anon data, if the vm_map_entry has an
amap. This adds three new debug "bits" to the -D argument, so the
namei cache dumping "bit" has been moved up.
Also, change the * that gets emitted with -vv to indicate the number
of pages skipped and the size of the area (in kilobytes).
better use of the submap names when dumping the kernel map, clean up
the "interface" between the main and LOCKDEBUG dependent pmap modules,
and make the heap identification work better.
VM_MAP_TOPDOWN flag (and the VM_MAP_DYING flag, since it never got
documented before), minor tweak to one of the examples, and use the
UVM_ET_IS*() macros instead of doing the same work manually.
would fail in spectacular ways on LOCKDEBUG kernels) by compiling the
groveler code twice (the second time with LOCKDEBUG defined so that
the appropriate structures get larger in the right way). We currently
decide if we are operating on a kernel with LOCKDEBUG enabled if the
kernel's vm_map has referential integrity between a few pointers
and/or values.
Also, if you use more than one -v, you get a * on a line by itself in
between gaps in entries. It makes finding gaps much easier visually.
