x86: Split most of pmap.h into pmap_private.h or vmparam.h.

This way pmap.h only contains the MD definition of the MI pmap(9)
API, which loads of things in the kernel rely on, so changing x86
pmap i

x86: Split most of pmap.h into pmap_private.h or vmparam.h.

This way pmap.h only contains the MD definition of the MI pmap(9)
API, which loads of things in the kernel rely on, so changing x86
pmap internals no longer requires recompiling the entire kernel every
time.

Callers needing these internals must now use machine/pmap_private.h.
Note: This is not x86/pmap_private.h because it contains three parts:

1. CPU-specific (different for i386/amd64) definitions used by...

2. common definitions, including Xenisms like xpmap_ptetomach,
further used by...

3. more CPU-specific inlines for pmap_pte_* operations

So {amd64,i386}/pmap_private.h defines 1, includes x86/pmap_private.h
for 2, and then defines 3. Maybe we should split that out into a new
pmap_pte.h to reduce this trouble.

No functional change intended, other than that some .c files must
include machine/pmap_private.h when previously uvm/uvm_pmap.h
polluted the namespace with pmap internals.

Note: This migrates part of i386/pmap.h into i386/vmparam.h --
specifically the parts that are needed for several constants defined
in vmparam.h:

VM_MAXUSER_ADDRESS
VM_MAX_ADDRESS
VM_MAX_KERNEL_ADDRESS
VM_MIN_KERNEL_ADDRESS

Since i386 needs PDP_SIZE in vmparam.h, I added it there on amd64
too, just to keep things parallel.

show more ...

make the max text size the same as the max data size

GC unused MAXTSIZ32

Move the UBC defaults into vmparam.h

We reorganise definitions for XEN source support as follows:

XEN - common sources required for baseline XEN support.
XENPV - sources required for support of XEN in PV mode.
XENPVHVM - sources requir

We reorganise definitions for XEN source support as follows:

XEN - common sources required for baseline XEN support.
XENPV - sources required for support of XEN in PV mode.
XENPVHVM - sources required for support for XEN in HVM mode.
XENPVH - sources required for support for XEN in PVH mode.

show more ...

Increase VM_PHYSSEG_MAX from 32 to 64. Saw an example on tech-kern@ of a
heavily fragmented memory map.

Make VM_MIN_KERNEL_ADDRESS and others available in the _KMEMUSER case
as well. This affects ddb. Tested by htodd.

Add #ifdef _KERNEL, vaddr_t does not exist in userland, and we don't want
externs anyway.

Randomize the main memory on Xen, same as native. Tested on amd64-dom0.

More ASLR: randomize the kernel main memory. VM_MIN_KERNEL_ADDRESS becomes
variable, and its location is chosen at boot time. There is room for
improvement, since for now we ask for an alignment of N

More ASLR: randomize the kernel main memory. VM_MIN_KERNEL_ADDRESS becomes
variable, and its location is chosen at boot time. There is room for
improvement, since for now we ask for an alignment of NBPD_L4.

This is enabled by default in GENERIC, but not in Xen. Tested extensively
on GENERIC and GENERIC_KASLR, XEN3_DOM0 still boots fine.

show more ...

Remove superfluous word in comment. Noted by Geoff Wing.

bump PAGER_MAP_DEFAULT_SIZE to 512MB. this should allow more
concurrent IOs to be possible, and i'm unable to see pager_map
contention any more.

other larger platforms should probably do this too.

bump PAGER_MAP_DEFAULT_SIZE to 512MB. this should allow more
concurrent IOs to be possible, and i'm unable to see pager_map
contention any more.

other larger platforms should probably do this too.

ok chs@.

show more ...

Update VM_DEFAULT_ADDRESS32_TOPDOWN to include guard area.

Recommit exec_subr.c revision 1.79:
Always include a 1MB guard area beyond the end of stack. While ASLR will
normally create a guard area as well, this provides a deterministic area
for all bin

Recommit exec_subr.c revision 1.79:
Always include a 1MB guard area beyond the end of stack. While ASLR will
normally create a guard area as well, this provides a deterministic area
for all binaries.

Mitigates the rest of CVE-2017-1000374 and CVE-2017-1000375 from
Qualys.

Additionally, change VM_DEFAULT_ADDRESS_TOPDOWN to include
user_stack_guard_size in the size reservation.

show more ...

Increase the kernel heap size from 512GB to 32TB, in such a way that it
is able to map the maximum amount of ram supported twice (16TB x 2).

Correct these values. They must be consistent with NKL4_MAX_ENTRIES,
otherwise the kernel thinks it has ~126TB of va while pmap knows it
has only 512GB.

Remove VM_MAX_KERNEL_BUF (unused). Looks like several other ports could
do the same.

Put a one-page redzone between userland and the PTE space on amd64 and
i386.

The PTE space is a critical region that maps the page tree, and bugs have
been found in both amd64 and i386 where the ker

Put a one-page redzone between userland and the PTE space on amd64 and
i386.

The PTE space is a critical region that maps the page tree, and bugs have
been found in both amd64 and i386 where the kernel would wrongly overflow
userland data on this area. This kind of bug is terrible, since it allows
userland to overwrite some entries of the page tree, which makes it easy
to patch the kernel text and get ring0 privileges.

show more ...

Remove unused <sys/tree.h>.

Add a FIRST1G page freelist to x86, for old graphics devices.

Tweak x86 page freelists and add x86_select_freelist.

- Add 4G freelist to i386 -- there may be higher addresses if PAE.
- Add 64G and 1T freelists to amd64.
- Simplify freelist setup code and conde

Tweak x86 page freelists and add x86_select_freelist.

- Add 4G freelist to i386 -- there may be higher addresses if PAE.
- Add 64G and 1T freelists to amd64.
- Simplify freelist setup code and condense it into a table.
- Add x86_select_freelist to get a freelist guaranteed to yield
addresses no greater than a prescribed maximum address.

x86_select_freelist takes a uint64_t, not a paddr_t or bus_addr_t, so
that you can pass in, e.g., a 36-bit maximum address without needing
to write conditionals for i386/PAE.

No objections on port-x86:

https://mail-index.netbsd.org/port-i386/2014/05/21/msg003277.html
https://mail-index.netbsd.org/port-amd64/2014/05/21/msg002062.html

show more ...

delete VM_DEFAULT_ADDRESS; some of those should be GC'ed because they match
the default definition.

provide propert address defaults for topdown and bottomup allocation

bump VM_PHYSSEG_MAX to 32, we've seen a system where 16 wasn't enough.

Bump VM_PHYSSEG_MAX to 16 from 10. Modern IBM hardware requires
VM_PHYSSEG_MAX to be turned up to 11 to avoid an early panic.